Mailing-List: contact ojb-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "OJB Developers List" <ojb-dev@db.apache.org>
Received-SPF: pass (hermes.apache.org: local policy)
Mime-Version: 1.0 (Apple Message framework v619)
In-Reply-To: <4149EDF0.3030302@gmx.ch>
References: <F23AA063-FA84-11D8-8508-000A95782782@forthillcompany.com>
 <41370118.9040108@gmx.ch>
 <6015C14F-FCDF-11D8-8C94-000A95782782@forthillcompany.com>
 <41374873.7030600@gmx.ch>
 <70DC8612-00CB-11D9-83EC-000A95782782@forthillcompany.com>
 <413DBE41.9020502@apache.org> <413F37CC.50907@gmx.ch>
 <413F3B13.4090909@apache.org> <41443697.8090900@gmx.ch>
 <F531CBD8-04B3-11D9-9C05-000A95782782@forthillcompany.com>
 <4149EDF0.3030302@gmx.ch>
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <3C92FE7C-081E-11D9-9BA2-000A95782782@forthillcompany.com>
Content-Transfer-Encoding: 7bit
From: Brian McCallister <mccallister@forthillcompany.com>
Subject: Re: [JDO] Help Needed!
Date: Thu, 16 Sep 2004 16:23:14 -0400
To: "OJB Developers List" <ojb-dev@db.apache.org>

This looks exactly right!

-Brian

On Sep 16, 2004, at 3:48 PM, Jakob Braeuchi wrote:

> hi brian,
>
> what is the difference between Criteria#addContains and the  
> Criteria#addIdentityEqualTo ?
>
> the sample below also return projects assigned to person(1):
>
> Person p = new Person();
> p.setId(1);
> p.setFirstname("tom");
> Identity id = broker.serviceIdentity().buildIdentity(p);
>
> Criteria crit = new Criteria();
> crit.addIdentityEqualTo("persons", id);
>
> Query q = QueryFactory.newQuery(Project.class, crit);
> Collection results = broker.getCollectionByQuery(q);
>
> // 2 Projects
> assertEquals(results.size(), 2);
>
> jakob
>
> Brian McCallister schrieb:
>
>> Awesome, thank you!
>> -Brian
>> On Sep 12, 2004, at 7:44 AM, Jakob Braeuchi wrote:
>>> hi armin, brian,
>>>
>>> i now have an implementation for IdentityCriterion. i'll do some   
>>> additional testing and i think i could submit it next week.
>>>
>>> the following test (and the ones using extents) all pass.
>>>
>>> jakob
>>>
>>> test1:
>>>
>>>         Person p = new Person();
>>>         p.setId(1);
>>>         Identity id = broker.serviceIdentity().buildIdentity(p);
>>>
>>>         Criteria crit = new Criteria();
>>>         crit.addIdentityEqualTo("", id);
>>>
>>>         Query q = QueryFactory.newQuery(Person.class, crit);
>>>         Collection results = broker.getCollectionByQuery(q);
>>>
>>>         // 1 person
>>>         assertEquals(results.size(), 1);
>>>
>>> test2:
>>>         Person p = new Person();
>>>         p.setId(1);
>>>         p.setFirstname("tom");
>>>         Identity id = broker.serviceIdentity().buildIdentity(p);
>>>
>>>         Criteria crit = new Criteria();
>>>         crit.addIdentityEqualTo("persons", id);
>>>
>>>         Query q = QueryFactory.newQuery(Project.class, crit);
>>>         Collection results = broker.getCollectionByQuery(q);
>>>
>>>         // 2 Projects
>>>         assertEquals(results.size(), 2);
>>>
>>>
>>> Armin Waibel schrieb:
>>>
>>>> Hi,
>>>> Jakob Braeuchi wrote:
>>>>
>>>>>> E.g. this is done in  
>>>>>> QueryByExample#buildCriteria(PersistenceBroker  aPb) instead of  
>>>>>> #buildCriteria().
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> i changed this to Query#preProcess(PersistenceBroker aPb) because   
>>>>> we'll need preprocessing for query-by-criteria as well.
>>>>>
>>>>>>
>>>>>> This way we can reuse the query object and it doesn't matter when  
>>>>>>  the PersistenceConfiguration was changed (something similar to  
>>>>>> the  metadata profiles in MM) before the next query. It is not   
>>>>>> guaranteed that the used metadata is the same on next use of the   
>>>>>> query, so we can't add this information statically.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> does this imply that i cannot store the result of the  
>>>>> preprocessing ?
>>>>
>>>> yep!
>>>>
>>>>> i was thinking of replacing the identity-criteria with a number of  
>>>>>  selectionCriteria during preprocessing.
>>>>>
>>>> This is not possible with current design/usage of classes Criteria   
>>>> and Query, because the user can reuse Criteria/Query build with   
>>>> broker for configuration A in a broker associated with  
>>>> configuration  B. Certainly most user will never do this, but it's  
>>>> allowed by  design.
>>>> regards,
>>>> Armin
>>>>
>>>>> jakob
>>>>>
>>>>>>
>>>>>> Does this shed some light on the issue?
>>>>>>
>>>>>> regards,
>>>>>> Armin
>>>>>>
>>>>>>
>>>>>>
>>>>>> Brian McCallister wrote:
>>>>>>
>>>>>>>
>>>>>>> On Sep 2, 2004, at 12:21 PM, Jakob Braeuchi wrote:
>>>>>>>
>>>>>>>> hi brian, armin,
>>>>>>>>
>>>>>>>> i was thinking about Criteria#addIdentityEqualTo(Identity anId).
>>>>>>>> is identity meant to be polymorphic ?
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> if by polymorphic you mean work across extents -- I would say   
>>>>>>> definitely yes.
>>>>>>>
>>>>>>> Identity(null, TopOfExtent.class, new Long[] { pk }) form would  
>>>>>>> be  good to support. I'll use it. if it is difficult to do,  
>>>>>>> should be  okay to postpone it for a while, or require a  
>>>>>>> concrete identity.
>>>>>>>
>>>>>>>> do we need Criteria#addIdentityEqualTo(Object anObj) where the   
>>>>>>>> identity is extracted from object ?
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Would be a convenience, but as you can obtain id's via the   
>>>>>>> serviceIdentity on PB, shouldn't be a requirement. Seems a  
>>>>>>> natural  convenience method to add, however.
>>>>>>>
>>>>>>>> we cannot translate the reference-criteria statically, because   
>>>>>>>> the MetadataManager issue armin posted previously. so may be we  
>>>>>>>>  need a preprocessing of the query where special criteria (or   
>>>>>>>> example objects) are translated into the standard-criteria.  
>>>>>>>> what  about this ?
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> What needs to be fixed in MM to get this to work the right way?   
>>>>>>> Re-reading Armin's post I am not sure what the problem is.
>>>>>>>
>>>>>>> -Brian
>>>>>>>
>>>>>>>>
>>>>>>>> jakob
>>>>>>>>
>>>>>>>> Brian McCallister schrieb:
>>>>>>>>
>>>>>>>>> On Sep 2, 2004, at 7:16 AM, Jakob Braeuchi wrote:
>>>>>>>>>
>>>>>>>>>> imo there are two solutions to this problem:
>>>>>>>>>>
>>>>>>>>>> 1.) construct the standard-criteria based on pk and pk-values  
>>>>>>>>>>  (like we do for query-by-example)
>>>>>>>>>> 2.) use a special identity- or reference-criteria that   
>>>>>>>>>> translates into a series of pk1=value1 etc. when building the  
>>>>>>>>>>  sql-statement.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Either way works for me -- you know that end of OJB a whole  
>>>>>>>>> lot  better than I do =)
>>>>>>>>> If I implemented it, I would probably approach  it as a   
>>>>>>>>> reference-criteria implemented internally using   
>>>>>>>>> standard-criteria and pk=value. I don't think this is   
>>>>>>>>> necessarily better, but is how I tend to think.
>>>>>>>>> -Brian
>>>>>>>>> --------------------------------------------------------------- 
>>>>>>>>> -- ----
>>>>>>>>> To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
>>>>>>>>> For additional commands, e-mail: ojb-dev-help@db.apache.org
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> ---------------------------------------------------------------- 
>>>>>>>> -- ---
>>>>>>>> To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
>>>>>>>> For additional commands, e-mail: ojb-dev-help@db.apache.org
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> ----------------------------------------------------------------- 
>>>>>>> -- --
>>>>>>> To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
>>>>>>> For additional commands, e-mail: ojb-dev-help@db.apache.org
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> ------------------------------------------------------------------ 
>>>>>> -- -
>>>>>> To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
>>>>>> For additional commands, e-mail: ojb-dev-help@db.apache.org
>>>>>>
>>>>>>
>>>>>
>>>>> ------------------------------------------------------------------- 
>>>>> --
>>>>> To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
>>>>> For additional commands, e-mail: ojb-dev-help@db.apache.org
>>>>>
>>>>>
>>>>>
>>>> -------------------------------------------------------------------- 
>>>> -
>>>> To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
>>>> For additional commands, e-mail: ojb-dev-help@db.apache.org
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
>>> For additional commands, e-mail: ojb-dev-help@db.apache.org
>>>
>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
>> For additional commands, e-mail: ojb-dev-help@db.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
> For additional commands, e-mail: ojb-dev-help@db.apache.org
>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-dev-help@db.apache.org