On Jan 14, 2008, at 1:46 AM, Lachlan Deck wrote:
> This would lead to something like the following wouldn't it? (e.g.,
> for a..um of columnA for rows satisfying the query)
>
> Select<Long> rawSelect = new Select<Long>(Long.class, "Artist");
> <...>
> List<Long> dataRows = context.performQuery(rawSelect);
>
> Problem is that Long is not guaranteed to be returned. It could very
> well be that the data type of the column, for example, targeted by
> the raw fetch could be mapped to an Integer.
>
> Whereas with a function like (public List<?> performRawQuery(...))
> that would seem to me to bypass those concerns.
>
> What do you think Andrus?
>
> with regards,
Yes, the "raw" query case from the generics perspective is as good as
casting (or as bad as casting).
IMO there's nothing wrong with it though as (a) this prevents the need
for casting and suppresses Eclipse warnings, (b) allows to do checking
for the type mismatch inside ObjectContext (so we can throw an
Exception inside 'performQuery' vs. user discovering it later when
iterating over the result).
Another positive side effect of it is that the method eliminates the
need for "setFetchingDataRows".
Andrus
This archive was generated by hypermail 2.0.0 : Mon Jan 14 2008 - 04:42:02 EST