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 Wed, 08 Sep 2004 16:48:12 GMT
hi armin, brian,

Armin Waibel schrieb:

> Hi Brian,
> 
>  > 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.
>  >
> 
> For example in method
> Criteria#addIdentityEqualTo(Object anObj)
> you need metadata information to extract the PK fields. It is allowed to 
> create the Criteria object without an PB instance and it is allowed to 
> reuse Criteria (and Query) objects.
> 
> In OJB 1.1 you need an PCKey/PBKey to lookup an PersistenceConfiguration 
> (with DescriptorRepository) from the MM and MM is no longer a singleton 
> (you have to use OJB main class OJB.java to lookup the MM).
> Both things are not possible when do
> crit = new Criteria()
> you don't know the used PBKey/PCKey and Criteria doesn't know about the 
> used OJB.java instance.
> Thus to create the query you have to pass a PB instance to the Criteria 
> object (each PB instance has an PersistenceConfiguration instance --> 
> solve all problems). This could be done in the PB instance itself when 
> call PB.getCollectionByQuery(...) or in any other query-method.
> 
> 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 ? i was 
thinking of replacing the identity-criteria with a number of selectionCriteria 
during preprocessing.

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


Mime
View raw message