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.
This archive was generated by hypermail 2.0.0 : Sun Jan 13 2008 - 18:26:25 EST