Quaere: LINQ Arrives for Java

Posted by Rob Thornton on Sep 20, 2007

Sections

Development

Topics

Java ,

Artifacts & Tools

Tags

LINQ

Anders Noras introduced the Quaere library, billed as LINQ for Java, last week at JavaZone. Quaere is a DSL providing query functionality against any structure implementing Iterable or its Queryable interface.

Noras lists the features of Quaere:

• Ability to perform queries against arrays or data structure implementing the Iterable interface.
• An internal DSL (based on static imports and fluent interfaces) that lets you integrate the query language with regular Java code. No preprocessing or code generation steps are required to use the DSL, simply add a reference to the quaere.jar file (and its dependencies).
• A large number of querying operators including restriction, selection, projection, set, partitioning, grouping, ordering, quantification, aggregation and conversion operators.
• Support for lambda expressions.
• The ability to dynamically define and instantiate anonymous classes.
• Many new “keywords” for Java 1.5 and later.

An example of retrieving a list of product name’s from a list of products is:

List products = Arrays.asList(Product.getAllProducts()); 
Iterable productNames =
 from("p").in(products).
 select("p.getProductName()"); 

Quaere currently has only one implementation (for objects), but a partial implementation is in place for Hibernate. The Hibernate implementation (and others with good criteria APIs) should progress quickly, Anders notes, as the demo of Hibernate only took a few hours.

Several people have noted that joSQL is a similar API. Anders himself notes the similarities but points out some key differences including:

• Quaere has better cohesion with the “business problem”
• Quaere queries are much more compact and have type safety
• Quaere is an extensible language that allows seamless addition of new querying engines

Lastly, Noras has made an attempt to answer common questions about Quaere and has created a project for it on Codehaus.

1. Back to top

   link broken

   by Runar Svendsen

   The Codehaus link at the end of the article is broken. This is the correct link.

   Reply

2. Back to top

   Type safety?

   by Peter Monks

   Given the use of strings in the select and presumably where clauses, is this truly type safe? Won't type safety require closures?

   Reply

3. Back to top

   Re: link broken

   by Rob Thornton

   Fixed the link. Thanks for the catch!

   Reply

4. Back to top

   Lost in HTML

   by Anders Norås

   First of all a big thank-you is due for writing about my humble project. Parts of the code example provided seem to have gotten "lost in HTML". Although the code in the example will compile and run, it should make use of generics to increase type safety.
   

   
   List<Product> products = Arrays.asList(Product.getAllProducts());
      Iterable<String> productNames =
              from("p").in(products).
              select("p.getProductName()");
   

   
   
   Cheers,
   Anders

   Reply

5. Back to top

   Type safety using decompilation

   by Thomas Mueller

   Using Strings does not provide type safety. With current Java it is still possible:
   

   Test t = db.alias(Test.class);
   db.from(t).where(t.id == 1).select(t.id, t.name);
   

   
   The problem here is how to convert 't.id == 1' and 't.id, t.name' into a expression tree (and then possibly SQL). Solution: get the calling class and line number. That's easy:
   

   StackTraceElement e = new Error().getStackTrace()[0];
   Class callingClass = e.getClass();
   String method = e.getMethodName();
   int line = e.getLineNumber();
   

   
   Now, get the byte code of the class, decompile this method (harder but possible), and extract the expression tree. It can be done.
   
   There are a few restrictions: 1) Requires debug info in the calling class. 2) Only one query per line of code. This can be solved: count how many times the method is called.
   
   Maybe I should add this feature to my database (www.h2database.com)

   Reply

6. Back to top

   Re: Type safety using decompilation

   by Thomas Mueller

   Ehm... one more problem: where(t.id == x)
   But this can be solved as well: Require that each parameter is listed:
   Query where(boolean condition, Object ... parameters)
   The the query becomes:
   where(t.id == x, x)
   The only problem now: You can't detect unknown parameters at regular compile time. This would require an additional compile step (_after_ the regular compilation). Any more problems?

   Reply

7. Back to top

   Type safety using objects

   by Thomas Mueller

   A solution without decompilation:
   

   class Test {
     Integer id;
     String name;
   }
   Test t = alias(Test.class);
   from(t).where(equal(t.id, x)).select(t.id, t.name);
   

   
   The method alias() would have to initialize the Test instance (assign a new object to each field). The methods equal() and select() could then check at runtime if such an object is passed and thus can reconstruct the expression tree. Disadvantages: int/long/double are not supported (except when using Integer.MIN_VALUE + 10, 11,..., but that would be a hack). A method is required for each operation (=, >, <, +,...).

   Reply

8. Back to top

   Type safety using objects / 2

   by Thomas Mueller

   If you drop the POJO requirement, you could even get more type savety:
   

   class Person {
       static final Person TABLE = Db.alias(Person.class);
       public DbInt id = DbInt.pk();
       public DbString name;
   }
   ...
   Person p = Person.TABLE;
   Person found = db.from(p).where(p.id.eq(10)).get();
   for (Person a : db.from(p).
       order(p.id.asc(), p.name.desc()).
       select()) {
     System.out.println(a.name.value);
   }
   Person one = db.from(p).
     where(p.id.eq(x).and(p.name.eq(name))).
     get();
   

   Reply

• Older >