On Jan 13, 2008, at 15:32, Andrus Adamchik wrote:
Since there was a clear dissatisfaction with all suggested
solutions, I kept trying other options. Here is one more attempt. I
ditched both ideas - to subclass existing queries and to implement
Query wrappers that are not queries themselves. Instead I combined
functionality of the existing queries and a user-friendly wrapper in
single new class that is itself a Query. As a result there's no
backwards compatibility issues allowing for the tight and clean API.
1. an example of usage... Notice that DataRows/Persistent/Generic
objects are all handled by the same query class:
Select<Artist> query1 = new Select<Artist>(Artist.class);
query1.andQualifier("artistName = 'ABC'")
.orQualifier("artistName = 'XYZ'")
.orderAscending(Artist.ARTIST_NAME_PROPERTY);
List<Artist> artists = context.performQuery(query1);
Nice.
2. here is an implementation draft... Omitted are SQLSelect,
NamedSelect, and ProcedureSelect. Also I think at the end "Select"
will be based internally on EJBQLQuery, not SelectQuery, as it has a
number of extra capabilities...
interface TypedQuery<T> extends Query {
}
interface ObjectContext {
List<T> performQuery(TypedQuery<T> query);
}
+1
So ... does the above sound acceptable, or are there still
reservations?
Nice work! I think this is getting very good. What do you think Andrus?
- Tore.
