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 <[EMAIL PROTECTED]> 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.
> >>>>
> >>>> 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]
> >>>>>
> >>>>>
> >>>>> --- [EMAIL PROTECTED] 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 <[EMAIL PROTECTED]>:
> >>>>>>
> >>>>>>
> >>>>>>> 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
