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).
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.
In a sense, the fecth 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.
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
dept.getEmployees();
// now the dept will load a collection of all Employees
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.
Pinaki Poddar
BEA Systems
415.402.7317
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
>> 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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
>>>> 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:[EMAIL PROTECTED] P.S. A good JDO? O, Gasp!
>>>>
>>>>
>>
>> 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!
>>
>>
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!
_______________________________________________________________________
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.
