OK by me, though I would prefer the language to be something more like
this is an area of non-portable (rather than forbidden) behavior. I.e.
no need for TCK test cases.
In reference to Bin Sun's question regarding the distinct keyword,
however, I don't think an implementation would need to check if the
Collections/Maps were .equal(); the spec doesn't say so explicitly, but
I assume that "distinct" applies to JDO identity, not Java equality, and
two Collections/Maps would only be nondistinct if they had multiple
owning objects (which is explicitly NOT mandated per 20.2).
Wes
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?
--- 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.
