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
>>
>>of type Collection)?
>>
>>>Perhaps I'm confusing the issue.
>>>
>>>Wes
>>>
>>>erik@jpox.org wrote:
>>>
>>>
>>>>Thanks Craig.
>>>>
>>>>If a map is projected, do we have two cells (key,
>>
>>value) or one cell with
>>
>>>type
>>>
>>>>Map.Entry ?
>>>>
>>>>I would expect it to be Map.Entry, what is in the
>>
>>spec?
>>
>>>>
>>>>
>>>
>>
>>
>>
>
>
> __________________________________________________
> Do You Yahoo!?
> Tired of spam? Yahoo! Mail has the best spam protection around
> http://mail.yahoo.com
--
Michael Bouschen Tech@Spree Engineering GmbH
mailto:mbo.tech@spree.de http://www.tech.spree.de/
Tel.:++49/30/235 520-33 Buelowstr. 66
Fax.:++49/30/2175 2012 D-10783 Berlin
|