On 14/01/2008, at 1:32 AM, 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);
That's good... but...
> Select<DataRow> query2 = new Select<DataRow>(DataRow.class, "Artist");
> query2.andQualifier("artistName = 'ABC'")
> .orQualifier("artistName = 'XYZ'")
> .orderAscending(Artist.ARTIST_NAME_PROPERTY);
> List<DataRow> dataRows = context.performQuery(query2);
I don't think this works. i.e., I don't think it's up to the user to
determine the type returned for a data row fetch. That's a function
of the framework as far as I see it.
How about this?
List<DataRow> dataRows = context.performRawQuery(query1)
with regards,
--Lachlan Deck
This archive was generated by hypermail 2.0.0 : Sun Jan 13 2008 - 16:57:55 EST