On 14/01/2008, at 1:32 AM, Andrus Adamchik wrote:
> 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);
> }
>
>
> public class Select<T> implements TypedQuery<T> {
>
> protected SelectQuery delegateQuery;
>
> public Select(Class<T> rootClass) {
> this.delegateQuery = new SelectQuery(rootClass);
> }
>
> public Select(Class<T> rootClass, String entityName) {
>
> if (entityName == null) {
> this.delegateQuery = new SelectQuery(rootClass);
> } else {
> this.delegateQuery = new SelectQuery(entityName);
>
> if (rootClass.isAssignableFrom(DataRow.class)) {
> delegateQuery.setFetchingDataRows(true);
> }
> }
> }
<...>
> So ... does the above sound acceptable, or are there still
> reservations?
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,
--Lachlan Deck
This archive was generated by hypermail 2.0.0 : Sun Jan 13 2008 - 18:46:40 EST