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
