I'm fine with your proposal. Thanks for clarifying that JDO vendors are still allowed to provide it as extension.
Regards, Erik Bengtson Quoting Craig L Russell <[EMAIL PROTECTED]>: > Javadogs, > > Based on this discussion, I'd like to propose that we restrict > projections to single-valued fields. What this means is that a > specification-compliant implementation must be able to throw an > exception if users try to project a multi-valued field or an > aggregate of a multi-valued field. > > If an implementation wants to allow users to project a multi-valued > field, they need to have the user set some configuration option, e.g. > org.errant.jdoimpl.option.query.MultiValuedFieldProjectionUseAtYourImmed > iateRisk. The TCK would run without this option set. > > Objections? > > Craig > > <proposed> > Specifying the Result of a Query (Projections, Aggregates) > The application might want to get results from a query that are not > instances of the candidate class. The results might be single-valued > fields of persistent instances, instances of classes other than the > candidate class, or aggregates of single-valued fields. > </proposed> > > > On Feb 15, 2006, at 11:31 AM, [EMAIL PROTECTED] wrote: > > > Hi Wes, > > > > Since an association has no identity, I would expect > > Collection.equals using JDO > > identity of the elements and owner, meaning 1 result. > > > > IMO, we don't have to define these semantics unless they are going > > to be set in > > the spec. > > > > Regards, > > > > Erik Bengtson > > > > Quoting Wes Biggs <[EMAIL PROTECTED]>: > > > >> I still contend that "distinct" does not imply the .equals() > >> operator, > >> and thus the answer would be > >> Collection1 [emp1,emp2,emp3] > >> Collection2 [emp1,emp2,emp3] > >> > >> Where Collection1 != Collection2 even though > >> Collection1.equals(Collection2). > >> > >> Consider an employee database with two men named John Smith and > >> datastore identity in use. I would expect "select distinct this from > >> Employee where name=='John Smith'" to return 2 results. > >> > >> Wes > >> > >> [EMAIL PROTECTED] wrote: > >> > >>> Hi Bin, > >>> > >>> > >>> > >>>> or result 2: > >>>> [emp1,emp2,emp3] > >>>> > >>>> > >>> > >>> The result would be 2 IMO according to what collection.equals > >>> contract says. > >>> > >>> For distinct queries, The easiest way is to evaluate it in > >>> memory. Of > >> course, > >>> optimal solutions may still apply. > >>> > >>> For non distinct queries, that's very simple and collections can > >>> be lazy > >> loaded. > >>> > >>> Quoting Bin Sun <[EMAIL PROTECTED]>: > >>> > >>> > >>> > >>>> Hi, Erik! > >>>> > >>>> I mean which would be the result? > >>>> > >>>> result 1: > >>>> [emp1,emp2,emp3] > >>>> [emp1,emp2,emp3] > >>>> > >>>> or result 2: > >>>> [emp1,emp2,emp3] > >>>> > >>>> ? > >>>> > >>>> If SQL 'distinct' used, we'll get result 1, I > >>>> guess. But as 'distinct' defined, the result should be > >>>> result 2, like a 'distinct name' query. > >>>> > >>>> --- [EMAIL PROTECTED] wrote: > >>>> > >>>> > >>>> > >>>>> Bin, > >>>>> > >>>>> Using distinct keyword the most database independent > >>>>> would be doing that in > >>>>> memory, but for some databases you can create stored > >>>>> procedures or UDFs. > >>>>> > >>>>> Regards, > >>>>> > >>>>> Quoting Bin Sun <[EMAIL PROTECTED]>: > >>>>> > >>>>> > >>>>> > >>>>>> Hi, erik! > >>>>>> > >>>>>> I'm curious. If we have two departments: > >>>>>> dept1 has employees: emp1, emp2, emp3 > >>>>>> dept2 has employees: emp1, emp2, emp3 > >>>>>> > >>>>>> (assume 'employees' is not a many-to-one relation) > >>>>>> > >>>>>> What will be the result of: (one or two result > >>>>>> row(s)?) > >>>>>> select distinct employees from Department > >>>>>> > >>>>>> and what SQL would be generated? > >>>>>> > >>>>>> --- [EMAIL PROTECTED] wrote: > >>>>>> > >>>>>> > >>>>>> > >>>>>>> -1. I vote for non-portable. It's simple to > >>>>>>> implement. > >>>>>>> > >>>>>>> Quoting Craig L Russell <[EMAIL PROTECTED]>: > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>>> Javadogs, > >>>>>>>> > >>>>>>>> If none of the implementations supports > >>>>>>>> > >>>>>>>> > >>>>>>> projections of collections or > >>>>>>> > >>>>>>> > >>>>>>>> maps, we can simply disallow it. If some do > >>>>>>>> > >>>>>>>> > >>>>>>> support it, we can say > >>>>>>> > >>>>>>> > >>>>>>>> it's not portable. > >>>>>>>> > >>>>>>>> For now, I'll propose disallowing it, and if > >>>>>>>> > >>>>>>>> > >>>>> there > >>>>> > >>>>> > >>>>>>> are > >>>>>>> > >>>>>>> > >>>>>>>> implementations out there we can change to > >>>>>>>> > >>>>>>>> > >>>>>>> non-portable. > >>>>>>> > >>>>>>> > >>>>>>>> <proposal 14.6.9> > >>>>>>>> Specifying the Result of a Query (Projections, > >>>>>>>> > >>>>>>>> > >>>>>>> Aggregates) > >>>>>>> > >>>>>>> > >>>>>>>> The application might want to get results from > >>>>>>>> > >>>>>>>> > >>>>> a > >>>>> > >>>>> > >>>>>>> query that are not > >>>>>>> > >>>>>>> > >>>>>>>> instances of the candidate class. The results > >>>>>>>> > >>>>>>>> > >>>>>>> might be single-valued > >>>>>>> > >>>>>>> > >>>>>>>> fields of persistent instances, instances of > >>>>>>>> > >>>>>>>> > >>>>>>> classes other than the > >>>>>>> > >>>>>>> > >>>>>>>> candidate class, or aggregates of > >>>>>>>> > >>>>>>>> > >>>>> single-valued > >>>>> > >>>>> > >>>>>>> fields. > >>>>>>> > >>>>>>> > >>>>>>>> </proposal 14.6.9> > >>>>>>>> > >>>>>>>> Craig > >>>>>>>> > >>>>>>>> On Feb 13, 2006, at 8:58 PM, Craig L Russell > >>>>>>>> > >>>>>>>> > >>>>>>> wrote: > >>>>>>> > >>>>>>> > >>>>>>>>> Hi Bin, > >>>>>>>>> > >>>>>>>>> I think it's confusing to project a > >>>>>>>>> > >>>>>>>>> > >>>>> collection > >>>>> > >>>>> > >>>>>>> or map in a query. > >>>>>>> > >>>>>>> > >>>>>>>>> The reason is that if there is a variable > >>>>>>>>> > >>>>>>>>> > >>>>> that > >>>>> > >>>>> > >>>>>>> derives from the > >>>>>>> > >>>>>>> > >>>>>>>>> same field as is being projected, the user > >>>>>>>>> > >>>>>>>>> > >>>>> might > >>>>> > >>>>> > >>>>>>> think that the > >>>>>>> > >>>>>>> > >>>>>>>>> field will be subject to the same > >>>>>>>>> > >>>>>>>>> > >>>>> constraints as > >>>>> > >>>>> > >>>>>>> the query, but > >>>>>>> > >>>>>>> > >>>>>>>>> this would be wrong. > >>>>>>>>> > >>>>>>>>> I'd rather we restrict projections of > >>>>>>>>> > >>>>>>>>> > >>>>> collection > >>>>> > >>>>> > >>>>>>> and map in > >>>>>>> > >>>>>>> > >>>>>>>>> queries. We can always add it later once we > >>>>>>>>> > >>>>>>>>> > >>>>>>> think more about > >>>>>>> > >>>>>>> > >>>>>>>>> whether it makes sense and has a strong > >>>>>>>>> > >>>>>>>>> > >>>>>>> justification. > >>>>>>> > >>>>>>> > >>>>>>>>> What can the user not do today if we > >>>>>>>>> > >>>>>>>>> > >>>>> restrict > >>>>> > >>>>> > >>>>>>> projection of > >>>>>>> > >>>>>>> > >>>>>>>>> collections and maps? If the user really > >>>>>>>>> > >>>>>>>>> > >>>>> wants > >>>>> > >>>>> > >>>>>>> to navigate to the > >>>>>>> > >>>>>>> > >>>>>>>>> collection or map field, then just project > >>>>>>>>> > >>>>>>>>> > >>>>> the > >>>>> > >>>>> > >>>>>>> instance and > >>>>>>> > >>>>>>> > >>>>>>>>> navigate to the fields of interest. > >>>>>>>>> > >>>>>>>>> Craig > >>>>>>>>> > >>>>>>>>> On Feb 13, 2006, at 6:27 PM, Bin Sun wrote: > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>>> Hi, all! > >>>>>>>>>> > >>>>>>>>>> Did anyone notice this? > >>>>>>>>>> > >>>>>>>>>> --- Bin Sun <[EMAIL PROTECTED]> wrote: > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>>> Hi! > >>>>>>>>>>> > >>>>>>>>>>> I have more concern about Collection > >>>>>>>>>>> > >>>>>>>>>>> > >>>>> and > >>>>> > >>>>> > >>>>>>> Map > >>>>>>> > >>>>>>> > >>>>>>>>>>> projection: is this query easy to > >>>>>>>>>>> > >>>>>>>>>>> > >>>>> implement? > >>>>> > >>>>> > >>>>>>>>>>> select distinct employees from Department > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>> where ... > >>>>>>> > >>>>>>> > >>>>>>>>>>> At least I don't know how a SQL datastore > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>> could > >>>>>>> > >>>>>>> > >>>>>>>>>>> compare the collections one another. > >>>>>>>>>>> > >>>>>>>>>>> So, maybe we should discribe more on > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>> Collection > >>>>>>> > >>>>>>> > >>>>>>>>>>> and Map projection, or simply specify that > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>> their > >>>>>>> > >>>>>>> > >>>>>>>>>>> distinction is the same as their owner > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>> objects, > >>>>>>> > >>>>>>> > >>>>>>>>>>> dispite whether they equal one another. > >>>>>>>>>>> > >>>>>>>>>>> --- [EMAIL PROTECTED] wrote: > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>>> Thanks for the comments, I agree with you > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>> all. > >>>>>>> > >>>>>>> > >>>>>>>>>>>> Regards, > >>>>>>>>>>>> > >>>>>>>>>>>> Quoting Michael Bouschen > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>> <[EMAIL PROTECTED]>: > >>>>> > >>>>> > >>>>>>>>>>>>> Hi, > >>>>>>>>>>>>> > >>>>>>>>>>>>> I have the same understanding of the > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>> semantics > >>>>>>> > >>>>>>> > >>>>>>>>>>> of > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>>> projections of > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>>> collection and map fields as Wes and Bin > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>> Sun. > >>>>>>> > >>>>>>> > >>>>>>>>>>> The > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>>> query would return the > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>>> collections or maps as single cells, so > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>> the > >>>>> > >>>>> > >>>>>>>>>>> query > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>>> result would be a list > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>>> of collections or maps. I also agree > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>> that > >>>>> > >>>>> > >>>>>>>>>>> support > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>>> for projections of > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>>> collection and map fields does not add > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>> much > >>>>> > >>>>> > >>>>>>>>>>> value, > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>>> but AFAIK the current > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>>> spec allows this. > >>>>>>>>>>>>> > >>>>>>>>>>>>> I think the shape of the query result is > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>> different > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>>> whether projecting a > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>>> collection field or including a variable > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>> in > >>>>> > >>>>> > >>>>>>> the > >>>>>>> > >>>>>>> > >>>>>>>>>>>> result that iterates the > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>>> collection: > >>>>>>>>>>>>> (1) SELECT employees FROM Department > >>>>>>>>>>>>> (2) SELECT e FROM Department WHERE > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>> employees.contains(e) > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>>> The first query returns a list of > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>> collections of > >>>>>>> > >>>>>>> > >>>>>>>>>>>> employees, so for each > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>>> department it returns the department's > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>> employee > >>>>>>> > >>>>>>> > >>>>>>>>>>>> collection. Query (2) > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>>> returns a list of employees, where each > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>> returned > >>>>>>> > >>>>>>> > >>>>>>>>>>>> employee is included in > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>>> an employee collection of at least one > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>> department. > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>>> Given the above is correct, JDOQL would > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>> never > >>>>>>> > >>>>>>> > >>>>>>>>>>>> return Map.Entry > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>>> instances. Either the query projects the > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>> entire > >>>>>>> > >>>>>>> > >>>>>>>>>>>> map or it iterates the > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>>> map using containsKey or containsValue, > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>> but > >>>>> > >>>>> > >>>>>>>>>>> there > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>>> is no contains for maps. > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>> === message truncated === > >>>> > >>>> > >>>> __________________________________________________ > >>>> Do You Yahoo!? > >>>> Tired of spam? Yahoo! Mail has the best spam protection around > >>>> http://mail.yahoo.com > >>>> > >>>> > >>>> > >>> > >>> > >>> > >>> > >> > >> > > > > > > > > Craig Russell > Architect, Sun Java Enterprise System http://java.sun.com/products/jdo > 408 276-5638 mailto:[EMAIL PROTECTED] > P.S. A good JDO? O, Gasp! > >
