db-jdo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Craig L Russell <Craig.Russ...@Sun.COM>
Subject Re: Negative VOTE Issue 159: Restrict projections to single-valued fields
Date Sun, 19 Feb 2006 22:54:13 GMT
Javadogs,

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.

Objections?

Craig

<proposed>
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.
</proposed>


On Feb 15, 2006, at 11:31 AM, erik@jpox.org wrote:

> Hi Wes,
>
> Since an association has no identity, I would expect  
> Collection.equals using JDO
> identity of the elements and owner, meaning 1 result.
>
> IMO, we don't have to define these semantics unless they are going  
> to be set in
> the spec.
>
> Regards,
>
> Erik Bengtson
>
> Quoting Wes Biggs <wes@tralfamadore.com>:
>
>> 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
>>
>> erik@jpox.org 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 <sun2bin@yahoo.com>:
>>>
>>>
>>>
>>>> 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.
>>>>
>>>> --- erik@jpox.org 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 <sun2bin@yahoo.com>:
>>>>>
>>>>>
>>>>>
>>>>>> 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?
>>>>>>
>>>>>> --- erik@jpox.org wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>>> -1. I vote for non-portable. It's simple to
>>>>>>> implement.
>>>>>>>
>>>>>>> Quoting Craig L Russell <Craig.Russell@Sun.COM>:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> 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 <sun2bin@yahoo.com> 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.
>>>>>>>>>>>
>>>>>>>>>>> --- erik@jpox.org wrote:
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>> Thanks for the comments, I agree with you
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>> all.
>>>>>>>
>>>>>>>
>>>>>>>>>>>> Regards,
>>>>>>>>>>>>
>>>>>>>>>>>> Quoting Michael Bouschen
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>> <mbo.tech@spree.de>:
>>>>>
>>>>>
>>>>>>>>>>>>> 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:Craig.Russell@sun.com
P.S. A good JDO? O, Gasp!


Mime
View raw message