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 > >> > >> > >> > > > > > > > > > >
