openjpa-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: possible to write a JPA Query to that filters both an Entity and its relationship entities?
Date Thu, 01 Mar 2007 18:20:10 GMT
Hi Pinaki,

On Feb 26, 2007, at 10:01 AM, Pinaki Poddar wrote:

> Respected Sir,
>> Sorry to disagree. If you fetch Department instances, I think you  
>> always want the _employees collection to contain all the related  
>> Employees.
>> You never want a filtered collection unless you provide a filter  
>> via some Java behavior.
> I agree that department.getEmployees() must return all the employees.
>
> However, i was considering the state of a Department instance in  
> memory
> that has just been selected by a query.  Which of the native  
> (String/int
> etc.) field values are populated and which of its related objects are
> instantiated is controlled by the currently active fetch plan (if not
> explicitly then at least implicitly by 'default' fetch group).

Right.

> If the application accesses any unrealized field  of this 'partially
> filled' department, then that field is populated irrespective of  
> whether
> it is in active fetch group or not via a new, separate database access
> call.

Right.

> In a sense, the fetch plan determines  a 'partial' view of the
> 'complete' department -- both in terms of its native state and its
> relations -- as and when it appears for the first time in memory. In
> fact, if the department instance leaves the managed environment via
> detachment at that point -- the detached department in a remote  
> process
> will only have this partially filled 'view'. And, of course, the
> application can explictly load any unrealized state of the partial  
> view
> via any getter method.

Right.
>
> I was trying to draw an equivalence/parallel of this normal fetch
> behavior to the use case where a owner object has a high,
> multi-cardinalty relationship but only wants a subset of the  
> elements of
> that relationship. In such a scheme, the traversal on a fetch path
> relation (which is now a binary decision) can be further adorned to
> support a predicate i.e.
> Query query = // a JPQL query that selects a Department based on some
> critria
> query.getFetchPlan().addField("employees", "yearsOfSevice>10");
> Department dept = query.getSingleResult();
> // dept will be constructed in memory with a collection of Employees
> with yearsOfService>10

The standard way to get the employees with the filter you show is to  
explicitly return the employee instances. The query language does not  
accommodate returning the collection as a result value. One of the  
reasons to exclude this is to disambiguate the result collection as  
being filtered or not. Disallowing return values of collection types  
neatly avoids the issue.

> dept.getEmployees();
> // now the dept will load a collection of all Employees

Right.

And you can also envision filtering the collection directly via non- 
standard techniques. Given the collection, that might not be fully  
instantiated, you can pass that collection to a proprietary method  
that does the filtering in the database.
>
> Of course, the suggested alternative approach where the application
> explictly constructs this partial/filtered multi-cardinality  
> relatinship
> by choosing the elements via query is feasible and available right now
> with current features.

Right.

Craig
>
>
> Pinaki Poddar
> BEA Systems
> 415.402.7317
>
>
> -----Original Message-----
> From: Craig.Russell@Sun.COM [mailto:Craig.Russell@Sun.COM]
> Sent: Friday, February 23, 2007 8:32 PM
> To: open-jpa-dev@incubator.apache.org
> Subject: Re: possible to write a JPA Query to that filters both an
> Entity and its relationship entities?
>
>
> On Feb 23, 2007, at 7:49 PM, Pinaki Poddar wrote:
>
>> One way to realize a owner object with a partially filled
>> multi-cardinality relationship is to expand fetchplan concept. For
>> example, if we consider a Department of 100 Employees of which  
>> only 20
>
>> are oldtimers, then a query can select the particular Department from
>> the datastore but to realize that Department as a Java object in
>> memory with only 20 senior Employees in _employees collection will
>> need to tune the fetch plan acconrdingly.
>> In JDO, fetch plan is specified to certain details to extract a  
>> subset
>> of native states and subset of relationships. JPA does not yet  
>> specify
>> fetch plan, but OpenJPA does via @FetchGroup extension. However
>> currently, no filtering criterion is applied to filter the content
>> while a particular relationship path is traversed. It is a
>> all-or-nothing affair. Either Department is fetched with all its 100
>> Employees or the Employees relation is not traversed at all. The only
>> control available now is to specify which native states and
>> relationship will be considered for fetching and in case of recursive
>> relationship how many times a particular relation path will be
>> traversed.
>> Essentially query and fecth paths are working in conjunction -- query
>> selects the root object and fetch plan decides which subset of the
>> closure of this root object is realized in memory.  It will surely be
>> a useful feature to consider expanding fetch plan with filtering
>> criteria.
>
> Sorry to disagree. If you fetch Department instances, I think you  
> always
> want the _employees collection to contain all the related  
> Employees. You
> never want a filtered collection unless you provide a filter via some
> Java behavior.
>
> In the query case, you want to get references to the filtered  
> instances
> but there's no connection to the _employees field of the department.
>
> This is a good thing.
>
> Craig
>>
>>
>>
>> Pinaki Poddar
>> BEA Systems
>> 415.402.7317
>>
>>
>> -----Original Message-----
>> From: Patrick Linskey
>> Sent: Friday, February 23, 2007 4:37 PM
>> To: open-jpa-dev@incubator.apache.org
>> Subject: RE: possible to write a JPA Query to that filters both an
>> Entity and its relationship entities?
>>
>> I would expect that your query would return the unfiltered employees
>> collection. But I have not run any tests.
>>
>> In other words, I would expect that the oldtimers collection would be
>> the full set of employees for each dept that had any oldtimers >= 15.
>>
>> That said, I don't think that your interpretation is necessarily
>> wrong.
>> Just not my expectation.
>>
>> -Patrick
>>
>> --
>> Patrick Linskey
>> BEA Systems, Inc.
>>
>> _____________________________________________________________________ 
>> _
>> _
>> Notice:  This email message, together with any attachments, may
>> contain
>> information  of  BEA Systems,  Inc.,  its subsidiaries  and
>> affiliated
>> entities,  that may be confidential,  proprietary,  copyrighted
>> and/or
>> legally privileged, and is intended solely for the use of the
>> individual or entity named in this message. If you are not the
>> intended recipient, and have received this message in error, please
>> immediately return this by email and then delete it.
>>
>>> -----Original Message-----
>>> From: Craig.Russell@Sun.COM [mailto:Craig.Russell@Sun.COM]
>>> Sent: Friday, February 23, 2007 4:14 PM
>>> To: open-jpa-dev@incubator.apache.org
>>> Subject: Re: possible to write a JPA Query to that filters both an
>>> Entity and its relationship entities?
>>>
>>> Hi Patrick,
>>>
>>>  From the JPQL
>>> select dept, oldtimers from Department dept LEFT JOIN
>>> dept.employeeCollection oldtimers WHERE dept.deptno >= 100 AND
>>> oldtimers.yearsOfService >= 15
>>>
>>> I expect to get SQL that looks something like select dept.id,
>>> dept.name, oldtimers.id, oldtimers.firstname, oldtimers.lastname,
>>> oldtimers.salary, oldtimers.ssn from Department dept, Employee
>>> oldtimers WHERE dept.id = oldtimers.deptid AND dept.deptno >= 100  
>>> AND
>>
>>> oldtimers.yearsOfService >= 15
>>>
>>> I then construct instances from the returned dept and oldtimers
>>> columns and give back to the user the results, with one result row
>>> for
>>
>>> each SQL ResultSet row. So the filtering from the JPQL translated
>>> into
>>
>>> the WHERE clause in the SQL should exclude oldtimers that don't
>>> qualify.
>>>
>>> If you don't use the oldtimers.yearsOfService >= 15 in the SQL, then
>>> you will get all of the employees in the department returned in the
>>> result. But why do you not use the oldtimers.yearsOfService >= 15 in
>>> the SQL?
>>>
>>> Craig
>>>
>>> On Feb 23, 2007, at 2:12 PM, Patrick Linskey wrote:
>>>
>>>>> In fact, you have to do a bit of work to get SQL to return you  
>>>>> non-
>>
>>>>> filtered instances. So I don't get it. Does OpenJPA not construct
>>>>> the obvious SQL that filters oldtimers?
>>>>
>>>> I don't think that you and I are really in sync here. Maybe
>>> some more
>>>> concrete examples are in order?
>>>>
>>>> -Patrick
>>>>
>>>> --
>>>> Patrick Linskey
>>>> BEA Systems, Inc.
>>>>
>>>>
>>> ______________________________________________________________
>>> ________
>>>> _
>>>> Notice:  This email message, together with any attachments, may
>>>> contain information  of  BEA Systems,  Inc.,  its subsidiaries  and
>>>> affiliated entities,  that may be confidential,  proprietary,
>>>> copyrighted and/or legally privileged, and is intended solely for
>>>> the use of the individual or entity named in this message. If you
>>>> are not the intended recipient, and have received this message in
>>>> error, please immediately return this by email and then delete it.
>>>>
>>>>> -----Original Message-----
>>>>> From: Craig.Russell@Sun.COM [mailto:Craig.Russell@Sun.COM]
>>>>> Sent: Friday, February 23, 2007 2:09 PM
>>>>> To: open-jpa-dev@incubator.apache.org
>>>>> Subject: Re: possible to write a JPA Query to that filters both an
>>>>> Entity and its relationship entities?
>>>>>
>>>>> So,
>>>>>
>>>>> I can tell you that having a result column that is filtered in the
>>>>> query is not what a user would expect. In JDO, the oldtimers  
>>>>> column
>>
>>>>> would be filtered.
>>>>>
>>>>> In fact, you have to do a bit of work to get SQL to return you  
>>>>> non-
>>
>>>>> filtered instances. So I don't get it. Does OpenJPA not construct
>>>>> the obvious SQL that filters oldtimers?
>>>>>
>>>>> I've re-read the JPA specification, and it appears to be silent on
>>>>> the issue of filtering. Is this a portability issue?
>>>>>
>>>>> Craig
>>>>>
>>>>> On Feb 23, 2007, at 1:57 PM, Tom Mutdosch wrote:
>>>>>
>>>>>> Hi Patrick,
>>>>>> Thanks for the query suggestion.  I guess what I was initially
>>>>>> thinking of doing was incorrect in that JPA doesn't really  
>>>>>> give me
>>
>>>>>> a "view" of what I want.  That is, I can never get a Department
>>>>>> object containing a list of filtered Employees.  A JPA object
>>>>>> returned from a query is always going to be an exact
>>>>> representation
>>>>>> of the database.  So your Department object is always going to
>>>>>> contain all of the Employees in its relationship.
>>>>>>
>>>>>> So like you mentioned, I can still get all the information using
>>>>>> one query, and then just process those results as I want them.  I
>>>>>> imagine that this would entail some sort of wrapper bean
>>>>> that would
>>>>>> house the Department and the filtered list of Employees.  Or what
>>>>>> if I added a regular method to my Department entity called
>>>>>> getFilterEmployees() which would return a List that I populated
>>>>>> with the filtered results from my query?  Does that seem like a
>>>>>> reasonable thing to do -- if I didn't want to deal with a wrapper
>>>>>> object but still have all of my desired data captured by a single
>>>>>> Entity?
>>>>>> Thanks
>>>>>> Tom
>>>>>>
>>>>>>
>>>>>> Patrick Linskey wrote:
>>>>>>> It is, but it doesn't buy you much in this situation --
>>>>> the oldTimers
>>>>>>> collection in your example won't be filtered to just the
>>>>> ones that
>>>>>>> are
>>>>>>> old. It'll be all the employees in the dept.
>>>>>>>
>>>>>>> -Patrick
>>>>>>>
>>>>>>>
>>>>>
>>>>> 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!
>>>
>>>
>
> 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!
>
> ______________________________________________________________________ 
> _
> Notice:  This email message, together with any attachments, may  
> contain
> information  of  BEA Systems,  Inc.,  its subsidiaries  and   
> affiliated
> entities,  that may be confidential,  proprietary,  copyrighted   
> and/or
> legally privileged, and is intended solely for the use of the  
> individual
> or entity named in this message. If you are not the intended  
> recipient,
> and have received this message in error, please immediately return  
> this
> by email and then delete it.

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