db-jdo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From e...@jpox.org
Subject Re: Negative VOTE Issue 159: Restrict projections to single-valued fields
Date Wed, 15 Feb 2006 19:31:48 GMT
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 <wes@tralfamadore.com>:

> 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
>
> erik@jpox.org 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 <sun2bin@yahoo.com>:
> >
> >
> >
> >>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.
> >>
> >>--- erik@jpox.org 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 <sun2bin@yahoo.com>:
> >>>
> >>>
> >>>
> >>>>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?
> >>>>
> >>>>--- erik@jpox.org wrote:
> >>>>
> >>>>
> >>>>
> >>>>>-1. I vote for non-portable. It's simple to
> >>>>>implement.
> >>>>>
> >>>>>Quoting Craig L Russell <Craig.Russell@Sun.COM>:
> >>>>>
> >>>>>
> >>>>>
> >>>>>>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 <sun2bin@yahoo.com> 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.
> >>>>>>>>>
> >>>>>>>>>--- erik@jpox.org wrote:
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>>Thanks for the comments, I agree with you
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>all.
> >>>>>
> >>>>>
> >>>>>>>>>>Regards,
> >>>>>>>>>>
> >>>>>>>>>>Quoting Michael Bouschen
> >>>>>>>>>>
> >>>>>>>>>>
> >>><mbo.tech@spree.de>:
> >>>
> >>>
> >>>>>>>>>>>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
> >>
> >>
> >>
> >
> >
> >
> >
>
>




Mime
View raw message