I still contend that "distinct" does not imply the .equals() operator,
and thus the answer would be
Collection1 [emp1,emp2,emp3]
Collection2 [emp1,emp2,emp3]
Where Collection1 != Collection2 even though
Collection1.equals(Collection2).
Consider an employee database with two men named John Smith and
datastore identity in use. I would expect "select distinct this from
Employee where name=='John Smith'" to return 2 results.
Wes
[EMAIL PROTECTED] wrote:
Hi Bin,
or result 2:
[emp1,emp2,emp3]
The result would be 2 IMO according to what collection.equals contract says.
For distinct queries, The easiest way is to evaluate it in memory. Of course,
optimal solutions may still apply.
For non distinct queries, that's very simple and collections can be lazy loaded.
Quoting Bin Sun <[EMAIL PROTECTED]>:
Hi, Erik!
I mean which would be the result?
result 1:
[emp1,emp2,emp3]
[emp1,emp2,emp3]
or result 2:
[emp1,emp2,emp3]
?
If SQL 'distinct' used, we'll get result 1, I
guess. But as 'distinct' defined, the result should be
result 2, like a 'distinct name' query.
--- [EMAIL PROTECTED] wrote:
Bin,
Using distinct keyword the most database independent
would be doing that in
memory, but for some databases you can create stored
procedures or UDFs.
Regards,
Quoting Bin Sun <[EMAIL PROTECTED]>:
Hi, erik!
I'm curious. If we have two departments:
dept1 has employees: emp1, emp2, emp3
dept2 has employees: emp1, emp2, emp3
(assume 'employees' is not a many-to-one relation)
What will be the result of: (one or two result
row(s)?)
select distinct employees from Department
and what SQL would be generated?
--- [EMAIL PROTECTED] wrote:
-1. I vote for non-portable. It's simple to
implement.
Quoting Craig L Russell <[EMAIL PROTECTED]>:
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?
--- 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.
=== message truncated ===
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
