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 Mon, 20 Feb 2006 16:17:53 GMT
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 <Craig.Russell@Sun.COM>:

> 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, erik@jpox.org 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 <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
> >>>>
> >>>>
> >>>>
> >>>
> >>>
> >>>
> >>>
> >>
> >>
> >
> >
> >
>
> Craig Russell
> Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
> 408 276-5638 mailto:Craig.Russell@sun.com
> P.S. A good JDO? O, Gasp!
>
>




Mime
View raw message