db-ojb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jakob Braeuchi <jbraeu...@gmx.ch>
Subject Re: [JDO] Help Needed!
Date Thu, 16 Sep 2004 19:48:00 GMT
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


Mime
View raw message