On 25/12/2007, at 2:20 AM, Andrus Adamchik wrote:
> - List<?> performQuery(Query query);
> + ..uppressWarnings("unchecked")
> + List performQuery(Query query);
>
I agree. Returning <?> from a function call does nothing for type
safety at all, so it may as well not be there. Pretty much everwhere
we return <?> from a function should be considered suspect and some of
the places <Object> can be found are also candidates for refactoring.
On 22/12/2007, at 2:53 AM, Andrus Adamchik wrote:
> The wrapper idea (SelectBuilder) is sort of along the lines of
> reversing the API that you suggested. But let me comment on why I am
> not a fan of adding new ways to run a query to the ObjectContext.
> When implementing ROP and nested contexts I found out that having so
> many "redundant" or "utility" methods in a context object makes it
> extremely hard to implement multi-layer contexts. So I'd prefer that
> we keep ObjectContext API as lean as possible, and pass all query
> parameters in the query object itself.
What we are discussing comes down to whether the query type (datarows
or persistent objects) should be injected into the Query as part of
the constructor (as per your new SelectBuilder or Tore's subclass
idea), sometime after (as per the existing Query) or when you want the
query executed (as per my idea with multiple return functions). Right
now I am looking at it from the point of view of an end-user : that is
really what we are talking about here. I really don't know the Query
code in enough depth to contribute to the decision about structuring
the code for multi-layer contexts. But I would have thought that any
functions like
List<Artists> result = query.getResult(Artist.class, context);
Map<String, Artists> result = query.getResultAsMap(Artist.class,
context, NAME_PROPERTY);
List<DataRow> result = query.getResultAsDataRows(Artist.class, context);
are just a thin veneer over the existing code much like your
SelectBuilder. What I like about it instead of making the choice at
constructor time is that user code might build a query in one place
but decide whether to return DataRows, PersistentObjects or even a
Map, Set, etc right at the point where the data is needed. That is,
queries could be more reusable than they are now. On the other hand
SelectQuery has oddities like addCustomDbAttribute() which imply the
need for a subclass such as Tore suggested (or a separate
implementation of the Query interface) - they have no place in a
SelectQuery which returns PersistentObjects.
I have to confess to not quite understanding the boundaries between
Expression and Query. 99% of the times that it is used, a Query is
just an Expression with Ordering and a root entity. But I don't
understand why that root entity isn't part of the Expression itself -
does an expression have much meaning without a root entity? It is
always implied within the Expression, since you can't create an
expression which is meaningful for Artist.class and then create a new
SelectQuery(Painting.class).
Ari Maniatis
-------------------------->
ish
http://www.ish.com.au
Level 1, 30 Wilson Street Newtown 2042 Australia
phone +61 2 9550 5001 fax +61 2 9550 4001
GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A
This archive was generated by hypermail 2.0.0 : Tue Dec 25 2007 - 21:14:53 EST