Sneak preview: Quaere for JPA

EntityManagerFactory entityManagerFactory = new EntityManagerFactoryImpl(sessionFactory, PersistenceUnitTransactionType.RESOURCE_LOCAL, true);
QueryableEntityManager entityManager = new QueryableEntityManager(entityManagerFactory.createEntityManager());

Iterable<Customer> waCustomers =
        from("c").in(entityManager.entity(Customer.class)).
                where(eq("c.getRegion()", "WA")).
                select("c");

for (Customer c : waCustomers) {
    log.info(c);
    Assert.assertEquals("WA", c.getRegion());
}

Comments

# Faraz Ahmed said on October 4, 2007 7:12 PM:

This is great!!!

I think there is only one thing missing, the var keyword in C# lets you keep a reference to an object of anonymous class and any access to members through that reference are type checked by compiler.

So it is possible to do something like

var result = [query].select({cus.id, cus.phone});

then one can say

print(result.get(0).id);

Also one can perform a join operation on customers and cities and return a list of some anonymous class like

var result = [query on customers and cities].select({customers.id, customers.phone, cities.name});

and then

print(result.get(0).name);

The point is that unavailability of var like facility in java is holding things back. Rest is awesome. I have heard that in java 7 we will have it.

Is it possible to pass select() a class and get the result  filled in objects of that class like:

class Result

{

   @from("City") public String name;

   @from("Customer") public String age;

   @from("Customer") public String id;

}

And then

List<Result> result = [query on customers and cities].select(Result.class);

The result class needs more thoughts. What if Customer also has name? one can play around with annotations.  If we want everything the we can also have

Class Result

{

public City city;

public Customer customer;

}

It got me really excited what you have done. Let me know if I can be of any help.

# andersnoras said on October 5, 2007 2:13 AM:

@Faraz;

First of all, thank you for you kind feedback. The var keyword is a huge benefit in C# 3.0 and makes the language feel more dynamic. Naturally, we cannot do compile time type inference in Java, so we've had to resort to using generics to control a query's return type. The convention in Quaere is that queries return an Iterable<T>, but there are convenience operators such as first, elementAt and similar that return a single element. Since you are familiar with LINQ, you'll probably recognize these operators.

While it hasn't been implemented in Quaere for JPA yet, Quaere actually supports join operatorions. Check out this post for an advanced example http://andersnoras.com/blogs/anoras/archive/2007/09/14/solving-puzzles-with-quaere.aspx

You should expect more advanced operators such as grouping, ordering and joins to be added to Quaere for JPA soon. You can also create anonymous classes with Quaere. The implementation in the trunk only produces instances of the org.quaere.Variant class, but there are plans to extend this to creating real JavaBeans. See http://jira.codehaus.org/browse/QUAERE-22

There has been done some work to enable construction of existing classes via queries, and the should be in place by the time Quaere has a release candidate.

If you'd like to participate in the project, contact me via the Quaere developer mailing list,  dev@quaere.codehaus.org, (or the contact form at this blog) and I'll help get you started.

# Faraz Ahmed said on October 6, 2007 11:13 AM:

I have sent a message through blog form providing my email address. Looking forward for your reply.

# Creating a fluent interface for Google Collections at Stephans Blog said on October 17, 2007 12:43 AM:

PingBack from http://stephan.reposita.org/archives/2007/10/17/creating-a-fluent-interface-for-google-collections/

# Anders Norås' Blog said on October 18, 2007 3:07 PM:

Some ever recurring discussions around Quaere are &#8220;this isn&#8217;t really LINQ for Java&#8221;

# Michael Hunger said on November 9, 2007 9:21 PM:

Hi Anders,

after getting frustrated with all those non syntactic, error prone SQL strings in the applications I work with. I started writing an embedded SQL DSL for Java, which unlike Quaere (which I hadn't read about by then :) stick with the sql syntax (less fellow developer adaption and readability problems).

Besides using expression trees for query parts, the whole query is also an expression tree.

I'm using generated class files from the database metadata to provide access to these datastructures when typing the queries, e.g. code completion, compile time safety, type checking and documentation lookup stuff.

Another thing that I find quite useful is not returning the selected objects but just giving them to a handler (like the spring jdbc handlers) for processing. I added an handler that accepts a Java Bean Interface in its callbacks where the resultset is mapped to the beans getter Methods or and callback method with primitive parameters to which the result set parameters are mapped directly.

Yesterday after two weeks of waiting I finally got my codehaus project.

Perhaps you'd like to have a look: http://jequel.de

Michael

Leave a Comment

Name (required) 

Your URL (optional)

Comments (required) 

Remember Me?

Enter the code you see below