You are viewing a plain text version of this content. The canonical link for it is here.
Posted to ojb-dev@db.apache.org by Brian McCallister <mc...@forthillcompany.com> on 2004/08/30 15:03:11 UTC
[JDO] Help Needed!
Hi again all. As lots of people said they wanted to help work on JDO
stuff, some things we need which are somewhat autonomous:
Support for equals criteria which matches object identity, so:
criteria.addEqualTo("objectReferenceOnCandidate", myWombat);
which will generate the correct code to match pk/fk
Support for a contains criteria:
criteria.addContains("collectionOnCandidate", myWombat);
which will generate correct where criteria. This one will be fun. This
will need to support object identity based query building like the
object reference equals.
Fetch Groups:
Read the JDO spec for explanation of this one. Is good stuff. Basically
override of proxy settings in our terms on a per-query basis.
JDO 2.0 Style mapping definitions:
Read the JDo spec for this one. Basically an alternate way of defining
mappings.
Any help on these is greatly appreciated! Thank you!
-Brian
---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-dev-help@db.apache.org
Re: [JDO] Help Needed!
Posted by Brian McCallister <mc...@forthillcompany.com>.
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
Re: [JDO] Help Needed!
Posted by Jakob Braeuchi <jb...@gmx.ch>.
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
Re: [JDO] Help Needed!
Posted by Brian McCallister <mc...@forthillcompany.com>.
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
Re: [JDO] Help Needed!
Posted by Jakob Braeuchi <jb...@gmx.ch>.
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
Re: [JDO] Help Needed!
Posted by Armin Waibel <ar...@apache.org>.
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
Re: [JDO] Help Needed!
Posted by Jakob Braeuchi <jb...@gmx.ch>.
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
Re: [JDO] Help Needed!
Posted by Armin Waibel <ar...@apache.org>.
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().
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 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
Re: [JDO] Help Needed!
Posted by Brian McCallister <mc...@forthillcompany.com>.
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
Re: [JDO] Help Needed!
Posted by Jakob Braeuchi <jb...@gmx.ch>.
hi brian, armin,
i was thinking about Criteria#addIdentityEqualTo(Identity anId).
is identity meant to be polymorphic ?
do we need Criteria#addIdentityEqualTo(Object anObj) where the identity is
extracted from object ?
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 ?
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
Re: [JDO] Help Needed!
Posted by Brian McCallister <mc...@forthillcompany.com>.
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
Re: [JDO] Help Needed!
Posted by Jakob Braeuchi <jb...@gmx.ch>.
hi brian,
Brian McCallister schrieb:
> Hi again all. As lots of people said they wanted to help work on JDO
> stuff, some things we need which are somewhat autonomous:
>
>
> Support for equals criteria which matches object identity, so:
>
> criteria.addEqualTo("objectReferenceOnCandidate", myWombat);
>
> which will generate the correct code to match pk/fk
>
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.
jakob
>
>
> Support for a contains criteria:
>
> criteria.addContains("collectionOnCandidate", myWombat);
>
> which will generate correct where criteria. This one will be fun. This
> will need to support object identity based query building like the
> object reference equals.
>
>
>
> Fetch Groups:
>
> Read the JDO spec for explanation of this one. Is good stuff. Basically
> override of proxy settings in our terms on a per-query basis.
>
>
>
> JDO 2.0 Style mapping definitions:
>
> Read the JDo spec for this one. Basically an alternate way of defining
> mappings.
>
>
> Any help on these is greatly appreciated! Thank you!
>
> -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