Re: distinct by owner? select distinct collectionField from SomeClass

[Craig L Russell]

Hi Bin,








Craig

On Feb 13, 2006, at 6:27 PM, Bin Sun wrote:

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.

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.

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

=== message truncated ===


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around
http://mail.yahoo.com

Craig Russell
Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
408 276-5638 mailto:[EMAIL PROTECTED]
P.S. A good JDO? O, Gasp!

smime.p7s
Description: S/MIME cryptographic signature