Re: Negative VOTE Issue 159: Restrict projections to single-valued fields

[Craig L Russell]

Javadogs,






Objections?

Craig

<proposed>
Specifying the Result of a Query (Projections, Aggregates)

</proposed>


On Feb 15, 2006, at 11:31 AM, [EMAIL PROTECTED] wrote:

Based on this discussion, I'd like to propose that we restrict projections to single-valued fields. What this means is that a specification-compliant implementation must be able to throw an exception if users try to project a multi-valued field or an aggregate of a multi-valued field. If an implementation wants to allow users to project a multi-valued field, they need to have the user set some configuration option, e.g. org.errant.jdoimpl.option.query.MultiValuedFieldProjectionUseAtYourImmed iateRisk. The TCK would run without this option set. 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.

Hi Wes,


identity of the elements and owner, meaning 1 result.


the spec.

Regards,

Erik Bengtson

Quoting Wes Biggs <[EMAIL PROTECTED]>:

Since an association has no identity, I would expect Collection.equals using JDO IMO, we don't have to define these semantics unless they are going to be set in

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

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