db-jdo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bin Sun <sun2...@yahoo.com>
Subject Re: distinct by owner? select distinct collectionField from SomeClass
Date Tue, 14 Feb 2006 05:59:18 GMT
I agree to disallow projection of collection and map
fields.

    I just saw Erik and Michael discussing this and
speak out my concern.

--- Craig L Russell <Craig.Russell@Sun.COM> 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.
> >>>>
> >>>> Regards Michael
> >>>>
> >>>>> Hi, all!
> >>>>>
> >>>>>     If I didn't miss anything in the spec, I
> >>> would
> >>>>> expect 'single-cell' result for a collection
> >> or
> >>> map
> >>>>> field, as if it is a simple field or reference
> >>> field.
> >>>>>
> >>>>>     eg.
> >>>>>
> >>>>> "select employees from Department"
> >>>>> -->
> >>>>> [employees of Dept 1]
> >>>>> [employees of Dept 2]
> >>>>> [employees of Dept 3]
> >>>>> ...
> >>>>>
> >>>>> Assume Student.scores: Map<Course, Float>
> >>>>> "select name, scores from Student"
> >>>>> -->
> >>>>> aaa,[scores map for aaa]
> >>>>> bbb,[scores map for bbb]
> >>>>> ccc,[scores map for ccc]
> >>>>>
> >>>>>
> >>>>> --- erik@jpox.org wrote:
> >>>>>
> >>>>>
> >>>>>> Actually, you can project a collection field,
> >>> but in
> >>>>>> fact what is projected are
> >>>>>> the elements of the collection.
> >>>>>>
> >>>>>> dept = {"dept1","dept2"}
> >>>>>> dept1.employees = {"emp1","emp2","emp3"}
> >>>>>> dept2.employees = {"emp4","emp5"}
> >>>>>>
> >>>>>> "select employees from Department" will
> result
> >>> in
> >>>>>>
> >>>>>> emp1
> >>>>>> emp2
> >>>>>> emp3
> >>>>>> emp4
> >>>>>> emp5
> >>>>>>
> >>>>>> "select this, employees from Department" will
> >>> result
> >>>>>> in
> >>>>>>
> >>>>>> dept1, emp1
> >>>>>> dept1, emp2
> >>>>>> dept1, emp3
> >>>>>> dept2, emp4
> >>>>>> dept2, emp5
> >>>>>>
> >>>>>> I would like to know what would that be in
> >> case
> >>> of
> >>>>>> Map or arrays.
> >>>>>>
> >>>>>> Quoting Wes Biggs <wes@tralfamadore.com>:
> >>>>>>
> >>>>>>
> >>>>>>> It doesn't make much sense to me to project
> >> to
> >>> map
> >>>>>>
> >>>>>> or collection fields,
> >>>>>>
> >>>>>>> though I don't see it explicitly discussed
> in
> >>> the
> >>>>>>
> >>>>>> spec. I suppose if we
> >>>>>>
> >>>>>>> allowed it, the cell would be of type Map or
> >>>>>>
> >>>>>> Collection (or etc. as
> >>>>>>
> >>>>>>> declared).  Or am I missing some kind of
> >>> automatic
> >>>>>>
> >>>>>> flattening function?
> >>>>>>
> >>>>>>> i.e., today can you do:
> >>>>>>> "select employees from Department" (returns
> >>> cells
> 
=== message truncated ===


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

Mime
View raw message