> Anyway, by using the two attached classes and superclass template, you can
> write type safe code
Wooo-hooo!
Not having type safety in queries has been one of my pet peeves about most ORMs.
> such as:
>
> List<User> users =
> User.fetch(
> dataContext,
> User.FIRSTNAME.like( "joe%" )
> .and(
> User.AGE.between( 20, 30 ),
> User.FIRSTNAME.asc().then( User.LASTNAME.asc() )
> );
>
> (this would fetch all users named "joe"-something, aged betweeen 20 and 30,
> and order the list by first name, then last name.
Seems like the standard mode of operation is constructing queries independently
of a data context.
I like that; in Hibernate, this is definitely a nonstandard mode of operation,
making it harder to pre-create queries.
Also, there's a typo in the example I think. Given the fetch() signatures, you
probably meant to say:
List<User> users =
User.fetch(
dataContext,
User.FIRSTNAME.like( "joe%" )
.and(User.AGE.between( 20, 30 )),
User.FIRSTNAME.asc().then( User.LASTNAME.asc() )
);
Let me toss around an idea, maybe somebody can build on it:
There's an awful lot of overloading going on with the generated fetch()
methods. The reader of the code would have to instantly spot which of the
parametes are Expressions and which are Ordering lists; unfortunately, the
difference between User.FIRSTNAME.like("joe%") and User.FIRSTNAME.asc()
requires reading four symbols before you see the difference.
I'd like to see something like
User.fetch( dataContext,
new Query(
User.FIRSTNAME.like( "joe%" )
.and(User.AGE.between( 20, 30 )))
.sort( User.FIRSTNAME.asc().then( User.LASTNAME.asc() )
)
Advantages with that:
1) conditions and ordering stand out,
2) the whole combination of Expression and Ordering can be stored and reused,
3) it's easy to add .groupBy later.
Disadvantage: it's a bit longer, you need an extra new Query() and an extra
sort().
Regards,
Jo
