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 Negative VOTE Issue 159: Restrict projections to single-valued fields
Date Tue, 14 Feb 2006 18:59:23 GMT
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.
>>>>>
>>>>> 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]
>>>>>>
>>>>>>
>>>>>> --- erik@jpox.org 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 <wes@tralfamadore.com>:
>>>>>>>
>>>>>>>
>>>>>>>> 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
>>>>>>>>
>>>>>>>> erik@jpox.org 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:Craig.Russell@sun.com
> P.S. A good JDO? O, Gasp!
>

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