db-jdo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Wes Biggs <...@tralfamadore.com>
Subject Re: Negative VOTE Issue 159: Restrict projections to single-valued fields
Date Wed, 15 Feb 2006 18:39:25 GMT
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
>>
>>    
>>
>
>
>  
>


Mime
View raw message