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
of type Collection)?
Perhaps I'm confusing the issue.
Wes
[EMAIL PROTECTED] 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 [EMAIL PROTECTED] Engineering GmbH
mailto:[EMAIL PROTECTED] http://www.tech.spree.de/
Tel.:++49/30/235 520-33 Buelowstr. 66
Fax.:++49/30/2175 2012 D-10783 Berlin
