| 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?
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.
Thanks for the comments, I agree with you all.
Regards,
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]
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.
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
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
=== message truncated ===
__________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around
Craig Russell P.S. A good JDO? O, Gasp!
Craig Russell P.S. A good JDO? O, Gasp! |
smime.p7s