ObjectCachePerBrokerImpl and ODMG?
Hi, Is it possible to use ObjectCachePerBrokerImpl and ODMG? I want to be able to use a single OJB instance throughout one thread and associate one ObjectCache with this thread. So far it seems that PersistenceBroker instances are created and closed as ODMG transactions are opened and commited. Cheers, --Bill. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
FK to non-PK relationship
I saw posts on the following subject, but didn't see any replies: If a persistent class A has a reference to a persistent class B, can the foreign key in class B point to a field that is NOT the primary key in class A? If my understanding is correct it's impossible to do right now, at least I can't see a way to declare such a relationship in the repository (I concede that such situations shouldn't occur, but consider legacy data). Anyway, I thought that perhaps as a quick fix, the concept of QueryCustomizer can be extended to reference-descriptors as well. This way the user can programmatically adjust the query and set the related fields. Cheers, --Bill. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Interesting (failing) scenario of FKs/PKs in PB
Interestingly it fails silently, because after the assertion of primary keys the storeToDb() simply returns. Maybe foreign references should be expanded before the primary keys are asserted... --Bill. - Original Message - From: "Armin Waibel" <[EMAIL PROTECTED]> To: "OJB Users List" <[EMAIL PROTECTED]> Sent: Wednesday, March 12, 2003 1:49 PM Subject: Re: Interesting (failing) scenario of FKs/PKs in PB > The test fails because after commit none object > was persisted to database. > > regards, > Armin > > - Original Message - > From: "V.B. Skrypnyk" <[EMAIL PROTECTED]> > To: "OJB Users List" <[EMAIL PROTECTED]>; "Armin Waibel" > <[EMAIL PROTECTED]> > Sent: Wednesday, March 12, 2003 10:37 PM > Subject: Re: Interesting (failing) scenario of FKs/PKs in PB > > > > Hi Armin, > > > > I can only see 2 slight variances from my case: > > 1. My class doesn't have an autoincrement primary key > > 2. The reference is set from an object that already exists (it's not > saved > > in the same transaction) > > > > I don't know if these variances are material. Does the test pass? (I > can't > > seem to compile the > > project, there seem to be some problems with the StatementManager) > > > > --Bill. > > > > > > - Original Message - > > From: "Armin Waibel" <[EMAIL PROTECTED]> > > To: "OJB Users List" <[EMAIL PROTECTED]> > > Sent: Wednesday, March 12, 2003 10:46 AM > > Subject: Re: Interesting (failing) scenario of FKs/PKs in PB > > > > > > > Hi Christian, Bill > > > > > > I currently add a new test case to demonstrate > > > the described behaviour. > > > Could you check if I hit the bull's eye. > > > See ReferenceTest#testRepositoryFKStore > > > > > > regards, > > > Armin > > > > > > - Original Message - > > > From: "Malinescu, Cristian" <[EMAIL PROTECTED]> > > > To: "'OJB Users List'" <[EMAIL PROTECTED]> > > > Sent: Wednesday, March 12, 2003 6:15 PM > > > Subject: RE: Interesting (failing) scenario of FKs/PKs in PB > > > > > > > > > Hi > > > Yes, I succeeded to this behaviour but only for Oracle, for MySQL > was > > > going > > > OK, > > > and for my typical situation I needed only one PK, no FK. > > > This was strange for me, and I posted one email on this theme last > week, > > > but > > > till > > > now no remark/comment. I'm using the PB basic API. > > > regards, > > > Cristian > > > > > > -Original Message- > > > From: V.B. Skrypnyk [mailto:[EMAIL PROTECTED] > > > Sent: Mittwoch, 12. März 2003 18:02 > > > To: OJB Users List > > > Subject: Re: Interesting (failing) scenario of FKs/PKs in PB > > > > > > > > > Has anyone else encountered this problem? > > > > > > --Bill. > > > > > > > Hi, > > > > > > > > The following fails to be stored by PersistenceBroker: > > > > > > > > I have a class ACL which has two primary keys: objectId and > userFK, > > > and > > > > userFK is also a foreign key tied to a reference of type User. If > I do > > > this: > > > > > > > > persistentBroker.beginTransaction(); > > > > ACL acl = new ACL(); > > > > acl.setObjectId( 100 ); > > > > acl.setUser( currentUser ); > > > > persistentBroker.store(acl); > > > > persistentBroker.commitTransaction(); > > > > > > > > Acl will not be saved. The reason seems to be because in the > > > storeToDb() > > > > method of the PersistentBroker, there first comes an assertion of > the > > > > PrimaryKeys and afterwards comes the assignment of all the foreign > > > keys. > > > In > > > > the scenario above the assertion of the primary keys will fail, > > > because > > > the > > > > userFK has not been assigned yet, so we have an incomplete set of > > > primary > > > > keys. This does work with the ODMG layer, probably because of a > > > different > > > > sequence of events during the storing of the object. > > > > > > > > I wonder if there should be a check whether a primary key is > shared by > > > the > > > > foreign k
Re: Interesting (failing) scenario of FKs/PKs in PB
Hi Armin, I can only see 2 slight variances from my case: 1. My class doesn't have an autoincrement primary key 2. The reference is set from an object that already exists (it's not saved in the same transaction) I don't know if these variances are material. Does the test pass? (I can't seem to compile the project, there seem to be some problems with the StatementManager) --Bill. - Original Message - From: "Armin Waibel" <[EMAIL PROTECTED]> To: "OJB Users List" <[EMAIL PROTECTED]> Sent: Wednesday, March 12, 2003 10:46 AM Subject: Re: Interesting (failing) scenario of FKs/PKs in PB > Hi Christian, Bill > > I currently add a new test case to demonstrate > the described behaviour. > Could you check if I hit the bull's eye. > See ReferenceTest#testRepositoryFKStore > > regards, > Armin > > - Original Message - > From: "Malinescu, Cristian" <[EMAIL PROTECTED]> > To: "'OJB Users List'" <[EMAIL PROTECTED]> > Sent: Wednesday, March 12, 2003 6:15 PM > Subject: RE: Interesting (failing) scenario of FKs/PKs in PB > > > Hi > Yes, I succeeded to this behaviour but only for Oracle, for MySQL was > going > OK, > and for my typical situation I needed only one PK, no FK. > This was strange for me, and I posted one email on this theme last week, > but > till > now no remark/comment. I'm using the PB basic API. > regards, > Cristian > > -Original Message- > From: V.B. Skrypnyk [mailto:[EMAIL PROTECTED] > Sent: Mittwoch, 12. März 2003 18:02 > To: OJB Users List > Subject: Re: Interesting (failing) scenario of FKs/PKs in PB > > > Has anyone else encountered this problem? > > --Bill. > > > Hi, > > > > The following fails to be stored by PersistenceBroker: > > > > I have a class ACL which has two primary keys: objectId and userFK, > and > > userFK is also a foreign key tied to a reference of type User. If I do > this: > > > > persistentBroker.beginTransaction(); > > ACL acl = new ACL(); > > acl.setObjectId( 100 ); > > acl.setUser( currentUser ); > > persistentBroker.store(acl); > > persistentBroker.commitTransaction(); > > > > Acl will not be saved. The reason seems to be because in the > storeToDb() > > method of the PersistentBroker, there first comes an assertion of the > > PrimaryKeys and afterwards comes the assignment of all the foreign > keys. > In > > the scenario above the assertion of the primary keys will fail, > because > the > > userFK has not been assigned yet, so we have an incomplete set of > primary > > keys. This does work with the ODMG layer, probably because of a > different > > sequence of events during the storing of the object. > > > > I wonder if there should be a check whether a primary key is shared by > the > > foreign key and allow that assignment before the assertion of the > primary > > keys is performed. Any ideas? > > > > Cheers, > > --Bill. > > > > > > - > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Interesting (failing) scenario of FKs/PKs in PB
Hi Armin, I can only see 2 slight variances from my case: 1. My class doesn't have an autoincrement primary key 2. The reference is set from an object that already exists (it's not saved in the same transaction) I don't know if these variances are material. Does the test pass? (I can't seem to compile the project, there seem to be some problems with the StatementManager) --Bill. - Original Message - From: "Armin Waibel" <[EMAIL PROTECTED]> To: "OJB Users List" <[EMAIL PROTECTED]> Sent: Wednesday, March 12, 2003 10:46 AM Subject: Re: Interesting (failing) scenario of FKs/PKs in PB > Hi Christian, Bill > > I currently add a new test case to demonstrate > the described behaviour. > Could you check if I hit the bull's eye. > See ReferenceTest#testRepositoryFKStore > > regards, > Armin > > - Original Message - > From: "Malinescu, Cristian" <[EMAIL PROTECTED]> > To: "'OJB Users List'" <[EMAIL PROTECTED]> > Sent: Wednesday, March 12, 2003 6:15 PM > Subject: RE: Interesting (failing) scenario of FKs/PKs in PB > > > Hi > Yes, I succeeded to this behaviour but only for Oracle, for MySQL was > going > OK, > and for my typical situation I needed only one PK, no FK. > This was strange for me, and I posted one email on this theme last week, > but > till > now no remark/comment. I'm using the PB basic API. > regards, > Cristian > > -Original Message- > From: V.B. Skrypnyk [mailto:[EMAIL PROTECTED] > Sent: Mittwoch, 12. März 2003 18:02 > To: OJB Users List > Subject: Re: Interesting (failing) scenario of FKs/PKs in PB > > > Has anyone else encountered this problem? > > --Bill. > > > Hi, > > > > The following fails to be stored by PersistenceBroker: > > > > I have a class ACL which has two primary keys: objectId and userFK, > and > > userFK is also a foreign key tied to a reference of type User. If I do > this: > > > > persistentBroker.beginTransaction(); > > ACL acl = new ACL(); > > acl.setObjectId( 100 ); > > acl.setUser( currentUser ); > > persistentBroker.store(acl); > > persistentBroker.commitTransaction(); > > > > Acl will not be saved. The reason seems to be because in the > storeToDb() > > method of the PersistentBroker, there first comes an assertion of the > > PrimaryKeys and afterwards comes the assignment of all the foreign > keys. > In > > the scenario above the assertion of the primary keys will fail, > because > the > > userFK has not been assigned yet, so we have an incomplete set of > primary > > keys. This does work with the ODMG layer, probably because of a > different > > sequence of events during the storing of the object. > > > > I wonder if there should be a check whether a primary key is shared by > the > > foreign key and allow that assignment before the assertion of the > primary > > keys is performed. Any ideas? > > > > Cheers, > > --Bill. > > > > > > - > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Interesting (failing) scenario of FKs/PKs in PB
Has anyone else encountered this problem? --Bill. > Hi, > > The following fails to be stored by PersistenceBroker: > > I have a class ACL which has two primary keys: objectId and userFK, and > userFK is also a foreign key tied to a reference of type User. If I do this: > > persistentBroker.beginTransaction(); > ACL acl = new ACL(); > acl.setObjectId( 100 ); > acl.setUser( currentUser ); > persistentBroker.store(acl); > persistentBroker.commitTransaction(); > > Acl will not be saved. The reason seems to be because in the storeToDb() > method of the PersistentBroker, there first comes an assertion of the > PrimaryKeys and afterwards comes the assignment of all the foreign keys. In > the scenario above the assertion of the primary keys will fail, because the > userFK has not been assigned yet, so we have an incomplete set of primary > keys. This does work with the ODMG layer, probably because of a different > sequence of events during the storing of the object. > > I wonder if there should be a check whether a primary key is shared by the > foreign key and allow that assignment before the assertion of the primary > keys is performed. Any ideas? > > Cheers, > --Bill. > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Reference descriptor woes
Hi Wally,
I think you are right. If the developer implements .equals() and .hashCode()
and OJB keys the objects on the hashCode then there should be no reason why
we would need to travel up the hierarchy chain. It adds a bit more
complexity to the inheritance implementation on the user's side, but the
optimization, I think, is worth it.
What do OJB gurus think?
--Bill.
- Original Message -
From: "Gelhar, Wallace J." <[EMAIL PROTECTED]>
To: "OJB Users List" <[EMAIL PROTECTED]>
Sent: Monday, March 10, 2003 6:57 AM
Subject: RE: Reference descriptor woes
There was a reason for this design.
Say there is an abstract class A and a concrete class B extending A. No
say there is a B instance b with a primary key value '17'.
If we do not use the toplevel extent to define Identies it could happen
that OJB addresses this object as A{17} or as B{17}.
this result would violate base rules like
if x == y then id(x) == id(y)
I'm confused...Why do you rely on == instead of .equals? As application
developers, we have to correctly implement .equals and .hashCode() to
guarantee identity when using Java 2 Collections. What is the reason
for using the address identity in OJB?
The reason I ask is I have a similar scenario, a base class of Foo with
two derived classes Foo_current and Foo_history used to store to an
"active" table or a "historical" table. Foo_active is an empty class
and history maintains some additional dates. In some cases, I want to
access all Foo's, regardless of active or history, but need efficient
access to the active Foo's when explicitly referenced. Currently, when
I access the Foo_active, OJB will search all Foo_active and Foo_history
(which is rather large) to find the object resulting in very slow
response times.
Any advise?
Wally
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Interesting (failing) scenario of FKs/PKs in PB
Hi, The following fails to be stored by PersistenceBroker: I have a class ACL which has two primary keys: objectId and userFK, and userFK is also a foreign key tied to a reference of type User. If I do this: persistentBroker.beginTransaction(); ACL acl = new ACL(); acl.setObjectId( 100 ); acl.setUser( currentUser ); persistentBroker.store(acl); persistentBroker.commitTransaction(); Acl will not be saved. The reason seems to be because in the storeToDb() method of the PersistentBroker, there first comes an assertion of the PrimaryKeys and afterwards comes the assignment of all the foreign keys. In the scenario above the assertion of the primary keys will fail, because the userFK has not been assigned yet, so we have an incomplete set of primary keys. This does work with the ODMG layer, probably because of a different sequence of events during the storing of the object. I wonder if there should be a check whether a primary key is shared by the foreign key and allow that assignment before the assertion of the primary keys is performed. Any ideas? Cheers, --Bill. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Reference descriptor woes
Hi Jakob,
I think I just found a simple solution. If I hide the top abstract class
from OJB all works well. It also doesn't compromise anything, since I never
reference the top level class anyway.
Cheers,
--Bill.
- Original Message -
From: "V.B. Skrypnyk" <[EMAIL PROTECTED]>
To: "OJB Users List" <[EMAIL PROTECTED]>
Sent: Sunday, March 09, 2003 2:22 AM
Subject: Re: Reference descriptor woes
> Hi Jakob,
>
> Can you drop me a hint as to what to search on. I did a search on
'identity'
> and 'extent' but nothing relevant came up. I am really interested in this
> problem because currently it makes it impossible for me to implement a
> persistent class which has a link to any other persistent class.
>
> Imagine that I have an ACL class. It has a reference to user and a
reference
> to a generic abstract persistent class. If I ensure (which I do) that my
> primary keys are unique across all tables in the db, I can easily verify
> permissions on any persistent class that I am working on. But if we travel
> up the extent hierarchy every time I need to reference concrete class from
> another concrete class then it means n db lookups where n is the number of
> tables in my database.
>
> Maybe there is some other method of implementing this kind of scenario in
> OJB that is not obvious to me. (BTW I have been snooping around the OJB
code
> and I have to say -- very lucid! easy to understand and work with)
>
> Cheers,
> --Bill.
>
>
> - Original Message -
> From: "Jakob Braeuchi" <[EMAIL PROTECTED]>
> To: "OJB Users List" <[EMAIL PROTECTED]>
> Sent: Sunday, March 09, 2003 1:40 AM
> Subject: Re: Reference descriptor woes
>
>
> > hi bill,
> >
> > there was a thread about the same issue in ojb-dev.
> >
> > this is what thomas posted:
> >
> > There was a reason for this design.
> > Say there is an abstract class A and a concrete class B extending A.
> > No say there is a B instance b with a primary key value '17'.
> >
> > If we do not use the toplevel extent to define Identies it could happen
> > that OJB addresses this object as A{17} or as B{17}.
> > this result would violate base rules like
> > if x == y then id(x) == id(y)
> >
> > We detected this issue a long time ago An I thaugt there was a testcase
> > covering it...
> >
> > hth
> > jakob
> >
> > V.B. Skrypnyk wrote:
> >
> > >Sorry, please disregard the previous post, I overlooked that this code
> isn't
> > >called when the loading is lazy.
> > >
> > >BUT, I am still a bit confused: in PersistenceBrokerImpl.java in method
> > >getReferencedObject() which is called from retrieveReference() there is
a
> > >line:
> > >
> > >// ensure that top-level extents are used for Identities
> > >referencedClass =
> descriptorRepository.getTopLevelClass(rds.getItemClass());
> > >
> > >I wonder why we need to go to the top of the extent hierarchy, since
the
> > >rds's class has been explicitely declared by the programmer. Because
what
> I
> > >noticed was that since I have a top class called SojbEntity which is
the
> > >superclass for all persistent classes in my app, it was the one looked
> for
> > >when the reference needed to be retrieved, so all tables where
basically
> > >scanned for the primary key equal to the value of the foreign key in
the
> > >class that had the reference.
> > >
> > >In other words, let's say we have the following hierarchy:
> > >
> > >SojbEntity
> > >|- Customer
> > >|- Contact
> > >|- User
> > >
> > >Customer has a reference to its administrator which is of class User.
If
> I
> > >ask for that reference to be retrieved, I don't want the
PersistentEntity
> to
> > >be searched, only User. Otherwise, Customer, Contact and User will be
> > >searched. Ideas?
> > >
> > >BTW, I replaced the line in the code above with code that just picks up
> the
> > >current ReferenceDescriptor class and it seemed to have eliminated the
> extra
> > >table lookups for me. Am I really breaking something here?
> > >
> > >Cheers,
> > >--Bill.
> > >
> > >
> > >- Original Message -
> > >From: "V.B. Skrypnyk" <[EMAIL PROTECTED]>
> > >To: "OJB Users List" <[EMAIL PROTECTED]>
> > >Sent: Saturday, March 08, 2003 9:02 PM
> > >Subject: Reference descriptor woes
> >
Re: Reference descriptor woes
Hi Jakob,
Can you drop me a hint as to what to search on. I did a search on 'identity'
and 'extent' but nothing relevant came up. I am really interested in this
problem because currently it makes it impossible for me to implement a
persistent class which has a link to any other persistent class.
Imagine that I have an ACL class. It has a reference to user and a reference
to a generic abstract persistent class. If I ensure (which I do) that my
primary keys are unique across all tables in the db, I can easily verify
permissions on any persistent class that I am working on. But if we travel
up the extent hierarchy every time I need to reference concrete class from
another concrete class then it means n db lookups where n is the number of
tables in my database.
Maybe there is some other method of implementing this kind of scenario in
OJB that is not obvious to me. (BTW I have been snooping around the OJB code
and I have to say -- very lucid! easy to understand and work with)
Cheers,
--Bill.
- Original Message -
From: "Jakob Braeuchi" <[EMAIL PROTECTED]>
To: "OJB Users List" <[EMAIL PROTECTED]>
Sent: Sunday, March 09, 2003 1:40 AM
Subject: Re: Reference descriptor woes
> hi bill,
>
> there was a thread about the same issue in ojb-dev.
>
> this is what thomas posted:
>
> There was a reason for this design.
> Say there is an abstract class A and a concrete class B extending A.
> No say there is a B instance b with a primary key value '17'.
>
> If we do not use the toplevel extent to define Identies it could happen
> that OJB addresses this object as A{17} or as B{17}.
> this result would violate base rules like
> if x == y then id(x) == id(y)
>
> We detected this issue a long time ago An I thaugt there was a testcase
> covering it...
>
> hth
> jakob
>
> V.B. Skrypnyk wrote:
>
> >Sorry, please disregard the previous post, I overlooked that this code
isn't
> >called when the loading is lazy.
> >
> >BUT, I am still a bit confused: in PersistenceBrokerImpl.java in method
> >getReferencedObject() which is called from retrieveReference() there is a
> >line:
> >
> >// ensure that top-level extents are used for Identities
> >referencedClass =
descriptorRepository.getTopLevelClass(rds.getItemClass());
> >
> >I wonder why we need to go to the top of the extent hierarchy, since the
> >rds's class has been explicitely declared by the programmer. Because what
I
> >noticed was that since I have a top class called SojbEntity which is the
> >superclass for all persistent classes in my app, it was the one looked
for
> >when the reference needed to be retrieved, so all tables where basically
> >scanned for the primary key equal to the value of the foreign key in the
> >class that had the reference.
> >
> >In other words, let's say we have the following hierarchy:
> >
> >SojbEntity
> >|- Customer
> >|- Contact
> >|- User
> >
> >Customer has a reference to its administrator which is of class User. If
I
> >ask for that reference to be retrieved, I don't want the PersistentEntity
to
> >be searched, only User. Otherwise, Customer, Contact and User will be
> >searched. Ideas?
> >
> >BTW, I replaced the line in the code above with code that just picks up
the
> >current ReferenceDescriptor class and it seemed to have eliminated the
extra
> >table lookups for me. Am I really breaking something here?
> >
> >Cheers,
> >--Bill.
> >
> >
> >- Original Message -
> >From: "V.B. Skrypnyk" <[EMAIL PROTECTED]>
> >To: "OJB Users List" <[EMAIL PROTECTED]>
> >Sent: Saturday, March 08, 2003 9:02 PM
> >Subject: Reference descriptor woes
> >
> >
> >
> >
> >>Hi,
> >>
> >>I am confused. Here is a snippet from the documentation:
> >>
> >>
> >>
> >>>>A proxy reference is based on the original proxy class concept. The
> >>>>
> >>>>
> >main
> >
> >
> >>difference is that the >>ReferenceDescriptor defines when to use a proxy
> >>class and not the ClassDescriptor.
> >>
> >>
> >>>>In the following mapping the class ProductGroup is not defined to be a
> >>>>
> >>>>
> >>proxy class in it's >>ClassDescriptor. Only for shown relationship a
proxy
> >>of ProductGroup should be used:
> >>
> >>Now this is the ObjectReferenceDescriptor.java snippet:
> >>
> >>public Class getItemProxyClass() throws PersistenceBrok
Re: Reference descriptor woes
Sorry, please disregard the previous post, I overlooked that this code isn't
called when the loading is lazy.
BUT, I am still a bit confused: in PersistenceBrokerImpl.java in method
getReferencedObject() which is called from retrieveReference() there is a
line:
// ensure that top-level extents are used for Identities
referencedClass = descriptorRepository.getTopLevelClass(rds.getItemClass());
I wonder why we need to go to the top of the extent hierarchy, since the
rds's class has been explicitely declared by the programmer. Because what I
noticed was that since I have a top class called SojbEntity which is the
superclass for all persistent classes in my app, it was the one looked for
when the reference needed to be retrieved, so all tables where basically
scanned for the primary key equal to the value of the foreign key in the
class that had the reference.
In other words, let's say we have the following hierarchy:
SojbEntity
|- Customer
|- Contact
|- User
Customer has a reference to its administrator which is of class User. If I
ask for that reference to be retrieved, I don't want the PersistentEntity to
be searched, only User. Otherwise, Customer, Contact and User will be
searched. Ideas?
BTW, I replaced the line in the code above with code that just picks up the
current ReferenceDescriptor class and it seemed to have eliminated the extra
table lookups for me. Am I really breaking something here?
Cheers,
--Bill.
- Original Message -
From: "V.B. Skrypnyk" <[EMAIL PROTECTED]>
To: "OJB Users List" <[EMAIL PROTECTED]>
Sent: Saturday, March 08, 2003 9:02 PM
Subject: Reference descriptor woes
> Hi,
>
> I am confused. Here is a snippet from the documentation:
>
> >> A proxy reference is based on the original proxy class concept. The
main
> difference is that the >>ReferenceDescriptor defines when to use a proxy
> class and not the ClassDescriptor.
> >>In the following mapping the class ProductGroup is not defined to be a
> proxy class in it's >>ClassDescriptor. Only for shown relationship a proxy
> of ProductGroup should be used:
>
> Now this is the ObjectReferenceDescriptor.java snippet:
>
> public Class getItemProxyClass() throws PersistenceBrokerException
> {
> if (m_ProxyOfItems == null)
> {
> m_ProxyOfItems = getClassDescriptor().getRepository().
> getDescriptorFor(m_ClassOfItems).getProxyClass(); <<<
proxy
> comes from descriptor
> }
> return m_ProxyOfItems;
> }
>
> The code goes to the reference class's class descriptor and tries to get
the
> proxy class from there, and the only way it can happen is if the proxy IS
> defined there. If this is correct, it means that the only way a reference
> proxy would work is if the class-descriptor for the corresponding
reference
> class is defined, contrary to the documentation. It also discards a fairly
> important optimization feature because now the user is confined to using
> proxies globally across any handling of the main class which will probably
> take a substantial hit during the population of collections.
>
> Is there something I am missing in this picture?
>
> --Bill.
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Possible Broker query bug?
Hi Jakob,
> hi bill,
>
> can i assume that every OR results in an OUTER JOIN ?
> if true i think fixing it is quite easy.
That would be my assumption.
--Bill.
> jakob
>
> V.B. Skrypnyk wrote:
>
> >Hi Scott,
> >
> >It seems you ran into exactly the same problem as I did (sorry I didn't
find
> >your post before posting mine). The workaround to the INNER JOIN problem
by
> >using report queries doesn't help in my case, because I modify an
existing
> >query by adding the restrictions (this is permissions oriented layer in
my
> >app). However, I think that this can be easily? fixed in the
> >SqlQueryStatement.java file. In fact I hacked a few lines of code to fix
the
> >bug, but not being very proficient with the OJB internals I don't know if
> >it's going to affect anything else.
> >
> >The relevant code follows:
> >
> >private void buildJoinTree(Criteria crit)
> >{
> >Enumeration e = crit.getElements();
> >
> >while (e.hasMoreElements())
> >{
> >Object o = e.nextElement();
> >if (o instanceof Criteria)
> >{
> >buildJoinTree((Criteria) o);
> >}
> >else
> >{
> >SelectionCriteria c = (SelectionCriteria) o;
> >if (c.getAttribute() != null)
> >{
> >buildJoinTreeForColumn(c.getAttribute(),
> >crit.getAlias(), ( crit.getType() == cr
> >it.OR ));
> >}
> >if (c instanceof FieldCriteria)
> >{
> >FieldCriteria cc = (FieldCriteria) c;
> > buildJoinTreeForColumn((String) cc.getValue(),
> >crit.getAlias(), (crit.getType()
> >== crit.OR ));
> >}
> >else if (c instanceof ColumnCriteria)
> >{
> >ColumnCriteria cc = (ColumnCriteria) c;
> >buildJoinTreeForColumn((String) cc.getValue(),
> >crit.getAlias(), (crit.getType()
> >== crit.OR ));
> >}
> >}
> >}
> >}
> >
> >and you also have to add the following method overloading the existing
one:
> >
> >private void buildJoinTreeForColumn(String aColName, String
aUserAlias,
> > boolean outerjoin )
> >{
> >String pathName = SqlHelper.cleanPath(aColName);
> >int sepPos = pathName.lastIndexOf(".");
> >
> >if (sepPos >= 0)
> >{
> >getTableAlias(pathName.substring(0, sepPos), outerjoin,
> >aUserAlias);
> >
> >}
> >}
> >
> >Basically, the gist is that if you get an OR criteria, any resulting join
> >based on it should be an outer one. Is this a correct assumption?
> >
> >This seems to have fixed the problem for me in the tests that I have.
> >
> >Cheers,
> >--Bill.
> >
> >- Original Message -
> >From: "Scott Howlett" <[EMAIL PROTECTED]>
> >To: "OJB Users List" <[EMAIL PROTECTED]>
> >Sent: Saturday, March 08, 2003 2:47 PM
> >Subject: RE: Possible Broker query bug?
> >
> >
> >I would also be interested to know whether this is considered to be a
> >bug. I mentioned it a while back:
> >
> >http://archives.apache.org/eyebrowse/[EMAIL PROTECTED]
> >pache.org&msgId=613222
> >
> >but never heard anything more.
> >
> >Regards,
> >Scott Howlett
> >
> >-Original Message-
> >From: V.B. Skrypnyk [mailto:[EMAIL PROTECTED]
> >Sent: Saturday, March 08, 2003 2:21 AM
> >To: OJB Users List
> >Subject: Possible Broker query bug?
> >
> >
> >I come across the following situation with PersistenceBroker queries:
> >
> >Here is my object
> >public class Customer {
> >...
> >private List acls = new Vector();
> >private String realm = "...";
> >}
> >
> >acls is a collection with Acl as collection member.
> >
> >This is the query
> >
> >Criteria crit = new Criteria();
> >crit.addEqualTo( "oid", new Long(201));
> >crit.addLike( "realm", "/201*" );
> >Criteria or = new Criteria();
> >or.addEqualTo( "acls.user_FK", new Long( 1 ) ); // notice the reference
> >field crit.addOrCriteria( or );
> >
>
Reference descriptor woes
Hi,
I am confused. Here is a snippet from the documentation:
>> A proxy reference is based on the original proxy class concept. The main
difference is that the >>ReferenceDescriptor defines when to use a proxy
class and not the ClassDescriptor.
>>In the following mapping the class ProductGroup is not defined to be a
proxy class in it's >>ClassDescriptor. Only for shown relationship a proxy
of ProductGroup should be used:
Now this is the ObjectReferenceDescriptor.java snippet:
public Class getItemProxyClass() throws PersistenceBrokerException
{
if (m_ProxyOfItems == null)
{
m_ProxyOfItems = getClassDescriptor().getRepository().
getDescriptorFor(m_ClassOfItems).getProxyClass(); <<< proxy
comes from descriptor
}
return m_ProxyOfItems;
}
The code goes to the reference class's class descriptor and tries to get the
proxy class from there, and the only way it can happen is if the proxy IS
defined there. If this is correct, it means that the only way a reference
proxy would work is if the class-descriptor for the corresponding reference
class is defined, contrary to the documentation. It also discards a fairly
important optimization feature because now the user is confined to using
proxies globally across any handling of the main class which will probably
take a substantial hit during the population of collections.
Is there something I am missing in this picture?
--Bill.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Possible Broker query bug?
Hi Scott,
It seems you ran into exactly the same problem as I did (sorry I didn't find
your post before posting mine). The workaround to the INNER JOIN problem by
using report queries doesn't help in my case, because I modify an existing
query by adding the restrictions (this is permissions oriented layer in my
app). However, I think that this can be easily? fixed in the
SqlQueryStatement.java file. In fact I hacked a few lines of code to fix the
bug, but not being very proficient with the OJB internals I don't know if
it's going to affect anything else.
The relevant code follows:
private void buildJoinTree(Criteria crit)
{
Enumeration e = crit.getElements();
while (e.hasMoreElements())
{
Object o = e.nextElement();
if (o instanceof Criteria)
{
buildJoinTree((Criteria) o);
}
else
{
SelectionCriteria c = (SelectionCriteria) o;
if (c.getAttribute() != null)
{
buildJoinTreeForColumn(c.getAttribute(),
crit.getAlias(), ( crit.getType() == cr
it.OR ));
}
if (c instanceof FieldCriteria)
{
FieldCriteria cc = (FieldCriteria) c;
buildJoinTreeForColumn((String) cc.getValue(),
crit.getAlias(), (crit.getType()
== crit.OR ));
}
else if (c instanceof ColumnCriteria)
{
ColumnCriteria cc = (ColumnCriteria) c;
buildJoinTreeForColumn((String) cc.getValue(),
crit.getAlias(), (crit.getType()
== crit.OR ));
}
}
}
}
and you also have to add the following method overloading the existing one:
private void buildJoinTreeForColumn(String aColName, String aUserAlias,
boolean outerjoin )
{
String pathName = SqlHelper.cleanPath(aColName);
int sepPos = pathName.lastIndexOf(".");
if (sepPos >= 0)
{
getTableAlias(pathName.substring(0, sepPos), outerjoin,
aUserAlias);
}
}
Basically, the gist is that if you get an OR criteria, any resulting join
based on it should be an outer one. Is this a correct assumption?
This seems to have fixed the problem for me in the tests that I have.
Cheers,
--Bill.
- Original Message -
From: "Scott Howlett" <[EMAIL PROTECTED]>
To: "OJB Users List" <[EMAIL PROTECTED]>
Sent: Saturday, March 08, 2003 2:47 PM
Subject: RE: Possible Broker query bug?
I would also be interested to know whether this is considered to be a
bug. I mentioned it a while back:
http://archives.apache.org/eyebrowse/[EMAIL PROTECTED]
pache.org&msgId=613222
but never heard anything more.
Regards,
Scott Howlett
-Original Message-
From: V.B. Skrypnyk [mailto:[EMAIL PROTECTED]
Sent: Saturday, March 08, 2003 2:21 AM
To: OJB Users List
Subject: Possible Broker query bug?
I come across the following situation with PersistenceBroker queries:
Here is my object
public class Customer {
...
private List acls = new Vector();
private String realm = "...";
}
acls is a collection with Acl as collection member.
This is the query
Criteria crit = new Criteria();
crit.addEqualTo( "oid", new Long(201));
crit.addLike( "realm", "/201*" );
Criteria or = new Criteria();
or.addEqualTo( "acls.user_FK", new Long( 1 ) ); // notice the reference
field crit.addOrCriteria( or );
Resulting sql statement is:
SELECT ... FROM customers A0 INNER JOIN acls A1 ON A0.cus_oid=A1.acl_eid
WHERE (A0.cus_oid = '201' ) AND A0.cus_realm LIKE '/201%' OR
(A1.acl_uid IN ( '1' ))
The sql statement comes out quite well constructed, except for one
thing. It uses inner join which means that my OR condition in which I
refer to a reference field effectually becomes an AND condition.
Shouldn't the statement contain rather left join in this case?
Cheers,
--Bill.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Possible Broker query bug?
I come across the following situation with PersistenceBroker queries:
Here is my object
public class Customer {
...
private List acls = new Vector();
private String realm = "...";
}
acls is a collection with Acl as collection member.
This is the query
Criteria crit = new Criteria();
crit.addEqualTo( "oid", new Long(201));
crit.addLike( "realm", "/201*" );
Criteria or = new Criteria();
or.addEqualTo( "acls.user_FK", new Long( 1 ) ); // notice the reference
field
crit.addOrCriteria( or );
Resulting sql statement is:
SELECT ... FROM customers A0 INNER JOIN acls A1 ON A0.cus_oid=A1.acl_eid
WHERE (A0.cus_oid = '201' ) AND A0.cus_realm LIKE '/201%' OR (A1.acl_uid
IN ( '1' ))
The sql statement comes out quite well constructed, except for one thing. It
uses inner join which means that my OR condition in which I refer to a
reference field effectually becomes an AND condition. Shouldn't the
statement contain rather left join in this case?
Cheers,
--Bill.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: ODMG recursive locking / ConcurrentModificationException
Hi Armin, I just did a cvs diff on the source and this is what I got: RCS file: /home/cvspublic/jakarta-ojb/src/java/org/apache/ojb/odmg/ObjectEnvelopeTable ..jav a,v retrieving revision 1.18 diff -r1.18 ObjectEnvelopeTable.java 63a64 > import java.util.Vector; 215c216,219 < iter = mvOrderOfIds.iterator(); --- > Vector tmp = new Vector(); > tmp.addAll( mvOrderOfIds ); > //iter = mvOrderOfIds.iterator(); > iter = tmp.iterator(); It seems that the source is the same as what I used when the problem came up. Are you sure that the changed file is ObjectEnvelopeTable.java. Is my revision right? --Bill. - Original Message - From: "Armin Waibel" <[EMAIL PROTECTED]> To: "OJB Users List" <[EMAIL PROTECTED]> Sent: Friday, March 07, 2003 12:55 AM Subject: Re: ODMG recursive locking / ConcurrentModificationException > Hi Bill, > > checked in that fix? yesterday after reading your post ;-) > Would be nice if you could try out my solution > (changed: ObjectEnvelopeTable.java). > > regards, > Armin > > - Original Message - > From: "V.B. Skrypnyk" <[EMAIL PROTECTED]> > To: "OJB Users List" <[EMAIL PROTECTED]> > Sent: Friday, March 07, 2003 8:21 AM > Subject: Re: ODMG recursive locking / ConcurrentModificationException > > > > Hi Armin, > > > > I modified the code manually by adding the temp vector solution. That > > worked. > > If your fix w/o temp vector was checked in the CVS before 2-3 days ago > > (that's when I encountered it in the newly downloaded CVS version), > > then the problem still persists. > > > > Cheers, > > --Bill. > > > > - Original Message - > > From: "Armin Waibel" <[EMAIL PROTECTED]> > > To: "OJB Users List" <[EMAIL PROTECTED]> > > Sent: Thursday, March 06, 2003 12:15 AM > > Subject: Re: ODMG recursive locking / ConcurrentModificationException > > > > > > > Hi Bill, > > > > > > I checked in a fix? in CVS without using a temp vector. > > > Did this solution works for you? > > > > > > regards, > > > Armin > > > > > > - Original Message - > > > From: "V.B. Skrypnyk" <[EMAIL PROTECTED]> > > > To: "OJB Users List" <[EMAIL PROTECTED]> > > > Sent: Thursday, March 06, 2003 7:32 AM > > > Subject: Re: ODMG recursive locking / > ConcurrentModificationException > > > > > > > > > > I just added code for a temporary vector and it worked. The change > > > below > > > > must have gotten lost. > > > > Or was there a problem with the solution? > > > > --Bill. > > > > > > > > - Original Message - > > > > From: "V.B. Skrypnyk" <[EMAIL PROTECTED]> > > > > To: "OJB Users List" <[EMAIL PROTECTED]> > > > > Sent: Wednesday, March 05, 2003 10:24 PM > > > > Subject: ODMG recursive locking / ConcurrentModificationException > > > > > > > > > > > > > Hi, > > > > > > > > > > I found a thread on the list > > > > > > > > > > > > > (http://archives.apache.org/eyebrowse/[EMAIL PROTECTED] > > > apac > > > > > he.org&msgId=593039) in which it is said: > > > > > >Indeed you stumbled across a bug in the ObjectEnvelopeTable > class. > > > The > > > > > >bug was fixed on 2002/12/23 13:27:59 which means it is not > > > available on > > > > > >version 0.9.8. It is however available directly from the cvs > > > server. > > > > > > > > > > > >The Concurrent Modification Exception occurs while upgrading > the > > > > > >locks in a commit operation of the ObjectEnvelopeTable class. > The > > > > > >solution we came up with was to iterate over temporary vector > while > > > > > >upgrading the locks. > > > > > > > > > > > >Cheers, > > > > > >Luis Cruz > > > > > I have just downloaded the latest cvs version, and I have the > same > > > > problem. > > > > > Did the change get lost by any chance? > > > > > --Bill > > > > > My stack trace: > > > > > [java] java.util.ConcurrentModificationException [java] > > > at > > > > > > > > > java.util.Abstr
Re: ODMG recursive locking / ConcurrentModificationException
Hi Armin, I modified the code manually by adding the temp vector solution. That worked. If your fix w/o temp vector was checked in the CVS before 2-3 days ago (that's when I encountered it in the newly downloaded CVS version), then the problem still persists. Cheers, --Bill. - Original Message - From: "Armin Waibel" <[EMAIL PROTECTED]> To: "OJB Users List" <[EMAIL PROTECTED]> Sent: Thursday, March 06, 2003 12:15 AM Subject: Re: ODMG recursive locking / ConcurrentModificationException > Hi Bill, > > I checked in a fix? in CVS without using a temp vector. > Did this solution works for you? > > regards, > Armin > > - Original Message - > From: "V.B. Skrypnyk" <[EMAIL PROTECTED]> > To: "OJB Users List" <[EMAIL PROTECTED]> > Sent: Thursday, March 06, 2003 7:32 AM > Subject: Re: ODMG recursive locking / ConcurrentModificationException > > > > I just added code for a temporary vector and it worked. The change > below > > must have gotten lost. > > Or was there a problem with the solution? > > --Bill. > > > > - Original Message - > > From: "V.B. Skrypnyk" <[EMAIL PROTECTED]> > > To: "OJB Users List" <[EMAIL PROTECTED]> > > Sent: Wednesday, March 05, 2003 10:24 PM > > Subject: ODMG recursive locking / ConcurrentModificationException > > > > > > > Hi, > > > > > > I found a thread on the list > > > > > > (http://archives.apache.org/eyebrowse/[EMAIL PROTECTED] > apac > > > he.org&msgId=593039) in which it is said: > > > >Indeed you stumbled across a bug in the ObjectEnvelopeTable class. > The > > > >bug was fixed on 2002/12/23 13:27:59 which means it is not > available on > > > >version 0.9.8. It is however available directly from the cvs > server. > > > > > > > >The Concurrent Modification Exception occurs while upgrading the > > > >locks in a commit operation of the ObjectEnvelopeTable class. The > > > >solution we came up with was to iterate over temporary vector while > > > >upgrading the locks. > > > > > > > >Cheers, > > > >Luis Cruz > > > I have just downloaded the latest cvs version, and I have the same > > problem. > > > Did the change get lost by any chance? > > > --Bill > > > My stack trace: > > > [java] java.util.ConcurrentModificationException [java] > at > > > > java.util.AbstractList$Itr.checkForComodification(AbstractList.java:444) > > > [java] [org.apache.ojb.odmg.ObjectEnvelopeTable] ERROR: Commit on > object > > > level failed for tx [EMAIL PROTECTED] > [java] > > > at java.util.AbstractList$Itr.next(AbstractList.java:417) [java] > > at > > > > > > org.apache.ojb.odmg.ObjectEnvelopeTable.commitAllEnvelopes(ObjectEnvelop > eTab > > > le.java:218) [java] at > > > > > > org.apache.ojb.odmg.ObjectEnvelopeTable.commit(ObjectEnvelopeTable.java: > 187) > > > [java] null [java] [org.apache.ojb.odmg.TransactionImpl] ERROR: > Could > > > not prepare for commit: null [java] at > > > > > > org.apache.ojb.odmg.TransactionImpl.doCommitOnObjects(TransactionImpl.ja > va:3 > > > 26) [java] at > > > > org.apache.ojb.odmg.TransactionImpl.prepare(TransactionImpl.java:575) > > > [java] at > > > org.apache.ojb.odmg.TransactionImpl.commit(TransactionImpl.java:525) > > > [java] at test.Test.main(Test.java:70) [java] > > > [org.apache.ojb.broker.accesslayer.ConnectionManagerImpl] INFO: > Rollback > > was > > > called, do rollback on current connection > > > [EMAIL PROTECTED] [java] > > > java.sql.SQLException: General error: Warning: Some > non-transactional > > > changed tables couldn't be rolled back [java] at > > > org.gjt.mm.mysql.MysqlIO.sendCommand(MysqlIO.java:497) [java] > > > [org.apache.ojb.broker.accesslayer.ConnectionManagerImpl] ERROR: > Rollback > > on > > > the underlying connection failed [java] at > > > org.gjt.mm.mysql.MysqlIO.sqlQueryDirect(MysqlIO.java:550) [java] > > at > > > org.gjt.mm.mysql.MysqlIO.sqlQuery(MysqlIO.java:635) [java] > General > > > error: Warning: Some non-transactional changed tables couldn't be > rolled > > > back [java] at > > > org.gjt.mm.mysql.Connection.execSQL(Connection.java:882) [java] >
Re: retreiveReference usage
Hi Jakob, That's what I expected... The kicker is auto-retrieve, it should be set to "true". Cheers, --Bill. - Original Message - From: "Jakob Braeuchi" <[EMAIL PROTECTED]> To: "OJB Users List" <[EMAIL PROTECTED]> Sent: Thursday, March 06, 2003 1:19 AM Subject: Re: retreiveReference usage > hi bill, > > there's no need to use getReference(), simply call obj.getMyCollection(). > refresh is used to reload relationships of already cached objects. > > hth > jakob > > V.B. Skrypnyk wrote: > > >When I call PersistenceBroker to retrieve an object by query and the object > >is defined > >to have collection proxies, should I expect to find CollectionProxy or > >ListProxy when > >I call object.getMyCollection() or am I supposed to call > >PersistenceBroker.retrieveReference() > >first? It seems that my list fields are not primed with CollectionProxies > >until I call retrieveReference > >explicitely. I've tried it with and without refresh="true" setting. Is this > >the desired behaviour? > > > >--Bill. > > > > > >- > >To unsubscribe, e-mail: [EMAIL PROTECTED] > >For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
retreiveReference usage
When I call PersistenceBroker to retrieve an object by query and the object is defined to have collection proxies, should I expect to find CollectionProxy or ListProxy when I call object.getMyCollection() or am I supposed to call PersistenceBroker.retrieveReference() first? It seems that my list fields are not primed with CollectionProxies until I call retrieveReference explicitely. I've tried it with and without refresh="true" setting. Is this the desired behaviour? --Bill. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: ODMG recursive locking / ConcurrentModificationException
I just added code for a temporary vector and it worked. The change below must have gotten lost. Or was there a problem with the solution? --Bill. - Original Message - From: "V.B. Skrypnyk" <[EMAIL PROTECTED]> To: "OJB Users List" <[EMAIL PROTECTED]> Sent: Wednesday, March 05, 2003 10:24 PM Subject: ODMG recursive locking / ConcurrentModificationException > Hi, > > I found a thread on the list > (http://archives.apache.org/eyebrowse/[EMAIL PROTECTED] > he.org&msgId=593039) in which it is said: > >Indeed you stumbled across a bug in the ObjectEnvelopeTable class. The > >bug was fixed on 2002/12/23 13:27:59 which means it is not available on > >version 0.9.8. It is however available directly from the cvs server. > > > >The Concurrent Modification Exception occurs while upgrading the > >locks in a commit operation of the ObjectEnvelopeTable class. The > >solution we came up with was to iterate over temporary vector while > >upgrading the locks. > > > >Cheers, > >Luis Cruz > I have just downloaded the latest cvs version, and I have the same problem. > Did the change get lost by any chance? > --Bill > My stack trace: > [java] java.util.ConcurrentModificationException [java] at > java.util.AbstractList$Itr.checkForComodification(AbstractList.java:444) > [java] [org.apache.ojb.odmg.ObjectEnvelopeTable] ERROR: Commit on object > level failed for tx [EMAIL PROTECTED] [java] > at java.util.AbstractList$Itr.next(AbstractList.java:417) [java] at > org.apache.ojb.odmg.ObjectEnvelopeTable.commitAllEnvelopes(ObjectEnvelopeTab > le.java:218) [java] at > org.apache.ojb.odmg.ObjectEnvelopeTable.commit(ObjectEnvelopeTable.java:187) > [java] null [java] [org.apache.ojb.odmg.TransactionImpl] ERROR: Could > not prepare for commit: null [java] at > org.apache.ojb.odmg.TransactionImpl.doCommitOnObjects(TransactionImpl.java:3 > 26) [java] at > org.apache.ojb.odmg.TransactionImpl.prepare(TransactionImpl.java:575) > [java] at > org.apache.ojb.odmg.TransactionImpl.commit(TransactionImpl.java:525) > [java] at test.Test.main(Test.java:70) [java] > [org.apache.ojb.broker.accesslayer.ConnectionManagerImpl] INFO: Rollback was > called, do rollback on current connection > [EMAIL PROTECTED] [java] > java.sql.SQLException: General error: Warning: Some non-transactional > changed tables couldn't be rolled back [java] at > org.gjt.mm.mysql.MysqlIO.sendCommand(MysqlIO.java:497) [java] > [org.apache.ojb.broker.accesslayer.ConnectionManagerImpl] ERROR: Rollback on > the underlying connection failed [java] at > org.gjt.mm.mysql.MysqlIO.sqlQueryDirect(MysqlIO.java:550) [java] at > org.gjt.mm.mysql.MysqlIO.sqlQuery(MysqlIO.java:635) [java] General > error: Warning: Some non-transactional changed tables couldn't be rolled > back [java] at > org.gjt.mm.mysql.Connection.execSQL(Connection.java:882) [java] at > org.gjt.mm.mysql.Connection.execSQL(Connection.java:815) [java] at > org.gjt.mm.mysql.Connection.rollback(Connection.java:551) [java] at > com.p6spy.engine.logging.P6LogConnection.rollback(P6LogConnection.java:145) > [java] at > org.apache.ojb.broker.accesslayer.ConnectionManagerImpl.localRollback(Connec > tionManagerImpl.java:245) [java] at > org.apache.ojb.broker.singlevm.PersistenceBrokerImpl.abortTransaction(Persis > tenceBrokerImpl.java:358) [java] at > org.apache.ojb.broker.singlevm.PersistenceBrokerImpl.close(PersistenceBroker > Impl.java:320) [java] at > org.apache.ojb.broker.singlevm.DelegatingPersistenceBroker.close(DelegatingP > ersistenceBroker.java:132) [java] at > org.apache.ojb.broker.singlevm.PoolablePersistenceBroker.close(PoolablePersi > stenceBroker.java:28) [java] at > org.apache.ojb.odmg.TransactionImpl.doClose(TransactionImpl.java:424) > [java] at > org.apache.ojb.odmg.TransactionImpl.commit(TransactionImpl.java:548) > [java] at test.Test.main(Test.java:70) [java] > org.odmg.TransactionAbortedException [java] at > org.apache.ojb.odmg.ObjectEnvelopeTable.commit(ObjectEnvelopeTable.java:198) > [java] at > org.apache.ojb.odmg.TransactionImpl.doCommitOnObjects(TransactionImpl.java:3 > 26) [java] at > org.apache.ojb.odmg.TransactionImpl.prepare(TransactionImpl.java:575) > [java] at > org.apache.ojb.odmg.TransactionImpl.commit(TransactionImpl.java:525) > [java] at test.Test.main(Test.java:70) [java] Exception in thread > "main" [java] Java Result: 1 > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
ODMG recursive locking / ConcurrentModificationException
Hi, I found a thread on the list (http://archives.apache.org/eyebrowse/[EMAIL PROTECTED] he.org&msgId=593039) in which it is said: >Indeed you stumbled across a bug in the ObjectEnvelopeTable class. The >bug was fixed on 2002/12/23 13:27:59 which means it is not available on >version 0.9.8. It is however available directly from the cvs server. > >The Concurrent Modification Exception occurs while upgrading the >locks in a commit operation of the ObjectEnvelopeTable class. The >solution we came up with was to iterate over temporary vector while >upgrading the locks. > >Cheers, >Luis Cruz I have just downloaded the latest cvs version, and I have the same problem. Did the change get lost by any chance? --Bill My stack trace: [java] java.util.ConcurrentModificationException [java] at java.util.AbstractList$Itr.checkForComodification(AbstractList.java:444) [java] [org.apache.ojb.odmg.ObjectEnvelopeTable] ERROR: Commit on object level failed for tx [EMAIL PROTECTED] [java] at java.util.AbstractList$Itr.next(AbstractList.java:417) [java] at org.apache.ojb.odmg.ObjectEnvelopeTable.commitAllEnvelopes(ObjectEnvelopeTab le.java:218) [java] at org.apache.ojb.odmg.ObjectEnvelopeTable.commit(ObjectEnvelopeTable.java:187) [java] null [java] [org.apache.ojb.odmg.TransactionImpl] ERROR: Could not prepare for commit: null [java] at org.apache.ojb.odmg.TransactionImpl.doCommitOnObjects(TransactionImpl.java:3 26) [java] at org.apache.ojb.odmg.TransactionImpl.prepare(TransactionImpl.java:575) [java] at org.apache.ojb.odmg.TransactionImpl.commit(TransactionImpl.java:525) [java] at test.Test.main(Test.java:70) [java] [org.apache.ojb.broker.accesslayer.ConnectionManagerImpl] INFO: Rollback was called, do rollback on current connection [EMAIL PROTECTED] [java] java.sql.SQLException: General error: Warning: Some non-transactional changed tables couldn't be rolled back [java] at org.gjt.mm.mysql.MysqlIO.sendCommand(MysqlIO.java:497) [java] [org.apache.ojb.broker.accesslayer.ConnectionManagerImpl] ERROR: Rollback on the underlying connection failed [java] at org.gjt.mm.mysql.MysqlIO.sqlQueryDirect(MysqlIO.java:550) [java] at org.gjt.mm.mysql.MysqlIO.sqlQuery(MysqlIO.java:635) [java] General error: Warning: Some non-transactional changed tables couldn't be rolled back [java] at org.gjt.mm.mysql.Connection.execSQL(Connection.java:882) [java] at org.gjt.mm.mysql.Connection.execSQL(Connection.java:815) [java] at org.gjt.mm.mysql.Connection.rollback(Connection.java:551) [java] at com.p6spy.engine.logging.P6LogConnection.rollback(P6LogConnection.java:145) [java] at org.apache.ojb.broker.accesslayer.ConnectionManagerImpl.localRollback(Connec tionManagerImpl.java:245) [java] at org.apache.ojb.broker.singlevm.PersistenceBrokerImpl.abortTransaction(Persis tenceBrokerImpl.java:358) [java] at org.apache.ojb.broker.singlevm.PersistenceBrokerImpl.close(PersistenceBroker Impl.java:320) [java] at org.apache.ojb.broker.singlevm.DelegatingPersistenceBroker.close(DelegatingP ersistenceBroker.java:132) [java] at org.apache.ojb.broker.singlevm.PoolablePersistenceBroker.close(PoolablePersi stenceBroker.java:28) [java] at org.apache.ojb.odmg.TransactionImpl.doClose(TransactionImpl.java:424) [java] at org.apache.ojb.odmg.TransactionImpl.commit(TransactionImpl.java:548) [java] at test.Test.main(Test.java:70) [java] org.odmg.TransactionAbortedException [java] at org.apache.ojb.odmg.ObjectEnvelopeTable.commit(ObjectEnvelopeTable.java:198) [java] at org.apache.ojb.odmg.TransactionImpl.doCommitOnObjects(TransactionImpl.java:3 26) [java] at org.apache.ojb.odmg.TransactionImpl.prepare(TransactionImpl.java:575) [java] at org.apache.ojb.odmg.TransactionImpl.commit(TransactionImpl.java:525) [java] at test.Test.main(Test.java:70) [java] Exception in thread "main" [java] Java Result: 1 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: PersistenceBrokerAware and current transaction
Thank you, Armin. I am using TxManagerFactory.instance().getCurrentTransaction() now. --Bill. - Original Message - From: "Armin Waibel" <[EMAIL PROTECTED]> To: "OJB Users List" <[EMAIL PROTECTED]> Sent: Monday, March 03, 2003 1:05 AM Subject: Re: PersistenceBrokerAware and current transaction > Hi Bill, > > ----- Original Message - > From: "V.B. Skrypnyk" <[EMAIL PROTECTED]> > To: "OJB Users List" <[EMAIL PROTECTED]> > Sent: Monday, March 03, 2003 7:28 AM > Subject: PersistenceBrokerAware and current transaction > > > > Hi, > > > > I am trying to implement my own cascading deletes of sorts through > > PersistenceBrokerAware beforeDelete callback. Strangely (?) I can't > seem to > > get the current transaction by calling: > > > > OJB.getInstance().currentTransaction() > > OJB isn't a singleton, thus when calling > OJB.getInstance() > you will get a new Implementation instance. > > regards, > Armin > > > > > so that I can add the affected dependent objects to it (so it may be > saved). > > I get the following exception: > > > > [java] org.odmg.DatabaseClosedException: Database is NULL, must have > a DB > > in order to create a transaction > > > > Is this correct behaviour? It's the same thread, shouldn't I be able > to > > retrieve the current transaction? > > > > Cheers, > > --Bill. > > > > > > - > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
PersistenceBrokerAware and current transaction
Hi, I am trying to implement my own cascading deletes of sorts through PersistenceBrokerAware beforeDelete callback. Strangely (?) I can't seem to get the current transaction by calling: OJB.getInstance().currentTransaction() so that I can add the affected dependent objects to it (so it may be saved). I get the following exception: [java] org.odmg.DatabaseClosedException: Database is NULL, must have a DB in order to create a transaction Is this correct behaviour? It's the same thread, shouldn't I be able to retrieve the current transaction? Cheers, --Bill. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Browsing of mailing list archives broken
If you want to access archives now, edit "db.apache.org" to "jakarta.apache.org" manually in the mailing list address in the url. It was overlooked when the site moved. --Bill. - Original Message - From: "ow" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Wednesday, February 26, 2003 9:32 PM Subject: Browsing of mailing list archives broken > Error occurred > Required parameter "listId" or "listName" is missing or invalid > > Hopefully, it'll be fixed soon. Thanks. > > > > > > > > > > > > __ > Do you Yahoo!? > Yahoo! Tax Center - forms, calculators, tips, more > http://taxes.yahoo.com/ > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: 1:M querys constraints
Thanks Jakob,
I am going to have a look at this later this week.
(What a great turn-around time! :)
--Bill.
- Original Message -
From: "Jakob Braeuchi" <[EMAIL PROTECTED]>
To: "OJB Users List" <[EMAIL PROTECTED]>
Sent: Wednesday, February 26, 2003 11:56 AM
Subject: Re: 1:M querys constraints
> hi all,
>
> i just added some fixes to support customizable 1:n queries.
> just add a query-customizer class to the collection-descriptor.
> this class must implement the QueryCustomizer interface, a
> QueryCustomizerDefaultImpl is alreay there as a base class.
>
>
>
> class="org.apache.ojb.broker.accesslayer.QueryCustomizerDefaultImpl">
>attribute-name="attr1"
> attribute-value="value1"
> />
>
>
> the interface defines the single method below which is used to customize
> (or completely rebuild) the query passed as argument. the interpretation
> of attribute-name ans attribute-value is up to your class !
>
> /**
> * Return a new Query based on the original Query, the originator
> object and
> * the additional Attributes
> *
> * @param anObject the originator object
> * @param aBroker the PersistenceBroker
> * @param aCod the CollectionDescriptor
> * @param aQuery the original 1:n-Query
> * @return Query the customized 1:n-Query
> */
> public Query customizeQuery(Object anObject, PersistenceBroker
> aBroker, CollectionDescriptor aCod, Query aQuery);
>
> hth
> jakob
>
>
> sclark wrote:
>
> >Jakob,
> >
> >You are correct; all of the logic is in the Builder class. As you say,
> >there are lots of possibilities for these constraints. I think that the
> >best way to express them is to use Java, rather than trying to invent
some
> >new syntax that fits inside of XML. And I bet that a fairly small set of
> >stock builders, appropriately parameterized, would hit the vast majority
> >of cases.
> >
> >Hmmm ... I bet it would be quite easy to write an OqlQueryBuilder
> >which would take a single parameter, an OQL string, and parse it.
> >Imagine this:
> >
> > > > name="recentOutsideProjects"
> > elementClass="Project"
> > ... >
> >
> >
> >>attribute-name="queryString"
> >attribute-value="project.startDate.year > 2000 and project.org <>
emp.org"
> > />
> >
> >
> >
> >Heck, maybe we could even write:
> >
> > > name="recentOutsideProjects"
> > elementClass="Project"
> > ... >
> >
> > > queryString="project.startDate.year > 2000 and project.org <>
emp.org"
> > />
> >
> >
> >One of the reasons that I prefer a Builder to a Refiner is that I have
> >relationships which don't involve FK's at all, so I'd like a way to
> >express those and never get any of the default Criteria in there. But
> >maybe it's sufficient to use a refinement approach, and make the FX spec
> >optional in repository.xml if there's a query. That way if I have FK's,
> >I can refine; if there aren't FK's, then I can just start from scratch.
> >
> >-steve
> >
> >
> >
> >
> >>From: Jakob Braeuchi <[EMAIL PROTECTED]>
> >>
> >>hi steve,
> >>
> >>what i miss in this approach is the operation (=, <>, like, between
etc.) .
> >>as far as i understand your proposal, the operation and the whole logic
> >>is dependent of the query-builder.
> >>this makes it quite easy for us to implement it in ojb, but it moves
> >>the burden of implementation to the user. especially when you think of
> >>accessing the 'originator' object as bill pointed out.
> >>
> >>as there are lots of possibilities for query-constraints, i'm not sure
> >>whether we'll be able to provide the most useful ones (from a user's
> >>point of view). on the other hand your approach provides all the
> >>flexibility one might need...
> >>
> >>imo we should just provide a standard query-restrictor using static
> >>parameters and operations for those who need simple restrictions only.
> >>
> >>just my 0.02 chf
> >>
> >>jakob
> >>
> >>sclark wrote:
> >>
> >>
> >>
> >>>Here's an idea on the collection restriction discussion. How about
something
> >>>like this:
> >>>
> >>>/**
> >>>* Interface implemented by classes which are used to create a custom
> >>>* query for the contents of a collection property, when the usual
> >>>* fk/pk approach is insufficient.
> >>>*/
> >>>interface org.apache.ojb.broker.query.QueryBuilder
> >>> /** Build the query to retrieve the specified collection property */
> >>> Query buildQuery(Object obj, ClassDescriptor cld,
CollectionDescriptor
> >>>
> >>>
> >cds);
> >
> >
> >>>}
> >>>
> >>>class PersistenceBrokerImpl {
> >>> private void retrieveCollection(...) {
> >>> if (cds.getQueryBuilder() != null)
> >>> {
> >>> fkQuery = cds.getQueryBuilder.buildQuery(obj, cld, cls);
> >>> }
> >>> else if (cds.isMtoNRelation())
> >>> {
> >>> fkQuery = getMtoNQuery(obj, cld, cds);
> >>> }
> >>> else
> >>> {
> >>> fkQuery = getForeignKeyQuery(obj,
Re: 1:M querys constraints
Hi Jacob, This seems to me to be an optimal solution. If I have the originator object, dynamic parameters are not an issue. --Bill. - Original Message - From: "Jakob Braeuchi" <[EMAIL PROTECTED]> To: "OJB Users List" <[EMAIL PROTECTED]> Sent: Friday, February 21, 2003 11:49 AM Subject: Re: 1:M querys constraints > hi bill, > > imo steve's proposal provides a lot more flexibility than mine. the > query restrictor will only modify the foreignKeyQuery it will not build > the whole query. so it needs the originator object and the > foreignKeyQuery based on the collection-descriptor, and what it does > with this query is up to the restrictor. i do not see a need for dynamic > metadata modifications so far. > > jakob > > V.B. Skrypnyk wrote: > > >Hi Steve, > > > > > > > >>It looks like you didn't send this to the list, only to me. > >> > >> > > > >Sorry, email client woes :(( > > > > > > > >>I wanted to clarify a couple of things, especially where you thought that > >> > >> > >my > > > > > >>approach would require extensive metadata mods. My intention is that the > >> > >> > >only > > > > > >>addition would be the element, which has a 'class' attribute and > >> > >> > >then > > > > > >>the existing custom tag. Knowledge of hard coded values, > >>child/parent references, AND/OR, etc. would be in the concrete Builder > >>implementation class itself - Java is a much better language than XML to > >> > >> > >express > > > > > >>this kind of stuff. > >> > >> > > > >I was referring to Jacob's suggestion -- yours doesn't require any major > >metadata > >extensions. > > > > > > > >>So, looking at my example, the BuildProjectsQuery would know its job is to > >> > >> > >add a > > > > > >>couple of criteria to handle the requested date range. The Builder would > >> > >> > >in > > > > > >>this case be specific to a particular relationship. A given Builder > >>implementation would document the specific attribute names (which really > >> > >> > >are > > > > > >>parameters, as you wrote) which it expected to find in its > >> > >> > >CollectionDescriptor. > > > >Still, how would you address dynamic parameters to your restricted queries. > >Your date range is a perfect example. I imagine you may want to change this > >range at runtime. Would you have to modify the metadata at runtime as well. > >Doing it this way seems a little scary, because you are then responsible for > >restoring the previous state if you don't want the changes to persist (even > >in the same thread). > > > > > > > >>As far as being overkill for a simple restriction, I was thinking that OJB > >> > >> > >would > > > > > >>eventually ship with a number of basic Builders - > >> > >> > >NonFKCollectionQueryBuilder, > > > > > >>ConstantFieldQueryBuilder, DateRangeQueryBuilder, etc. That way we get > >> > >> > >the best > > > > > >>of both worlds - simple end-user specification of simple restrictions, and > >> > >> > >lots > > > > > >>of flexibility for those who need it. > >> > >> > > > >The reason why I suggested to do a callback was because from the user > >perspective I am ignorant of the way that the association between the > >objects is constructed -- I am only interested in restricting that > >association. So if a collection descriptor specifies an M:N relationship or > >1:N relationship I felt it would be a duplication of an already existing > >mechanism to replicate logic how to construct these queries in a custom > >query builder, if I only need to restrict it. Perhaps, one may argue that > >you also have to know enough about the query to be able to modify it in the > >callback... > > > >Regards, > >--Bill > > > > > > > >>-steve > >> > >> > >> > >>>Date: Fri, 21 Feb 2003 10:13:30 -0800 (GMT-08:00) > >>>From: V B Skrypnyk <[EMAIL PROTECTED]> > >>>To: sclark <[EMAIL PROTECTED]> > >>>Subject: Re: 1:M querys constraints > >>> > >>>
Re: 1:M querys constraints
Hi Steve,
> It looks like you didn't send this to the list, only to me.
Sorry, email client woes :((
> I wanted to clarify a couple of things, especially where you thought that
my
> approach would require extensive metadata mods. My intention is that the
only
> addition would be the element, which has a 'class' attribute and
then
> the existing custom tag. Knowledge of hard coded values,
> child/parent references, AND/OR, etc. would be in the concrete Builder
> implementation class itself - Java is a much better language than XML to
express
> this kind of stuff.
I was referring to Jacob's suggestion -- yours doesn't require any major
metadata
extensions.
> So, looking at my example, the BuildProjectsQuery would know its job is to
add a
> couple of criteria to handle the requested date range. The Builder would
in
> this case be specific to a particular relationship. A given Builder
> implementation would document the specific attribute names (which really
are
> parameters, as you wrote) which it expected to find in its
CollectionDescriptor.
Still, how would you address dynamic parameters to your restricted queries.
Your date range is a perfect example. I imagine you may want to change this
range at runtime. Would you have to modify the metadata at runtime as well.
Doing it this way seems a little scary, because you are then responsible for
restoring the previous state if you don't want the changes to persist (even
in the same thread).
> As far as being overkill for a simple restriction, I was thinking that OJB
would
> eventually ship with a number of basic Builders -
NonFKCollectionQueryBuilder,
> ConstantFieldQueryBuilder, DateRangeQueryBuilder, etc. That way we get
the best
> of both worlds - simple end-user specification of simple restrictions, and
lots
> of flexibility for those who need it.
The reason why I suggested to do a callback was because from the user
perspective I am ignorant of the way that the association between the
objects is constructed -- I am only interested in restricting that
association. So if a collection descriptor specifies an M:N relationship or
1:N relationship I felt it would be a duplication of an already existing
mechanism to replicate logic how to construct these queries in a custom
query builder, if I only need to restrict it. Perhaps, one may argue that
you also have to know enough about the query to be able to modify it in the
callback...
Regards,
--Bill
> -steve
>
> >Date: Fri, 21 Feb 2003 10:13:30 -0800 (GMT-08:00)
> >From: V B Skrypnyk <[EMAIL PROTECTED]>
> >To: sclark <[EMAIL PROTECTED]>
> >Subject: Re: 1:M querys constraints
> >
> >Hi,
> >
> >I would agree with Steve's approach. I think it would require fairly
> >extensive configuration addition to metadata to support all
> >possible types of restrictions, as they can reference hard coded
> >values, as well as references to child and/or parent fields
> >(with appended hard coded tokens like '%' for like restrictions),
> >as well as AND / OR, etc.
> >
> >On the other hand, having a wholly custom query defined for
> >a collection may be an overkill for a simple restriction. Perhaps,
> >it may simplify matters, if there is a provision for a callback class
> >that would modify a naturally existing association, like so:
> >
> > > name="projects"
> > elementClass="gov.doi.cap.ojb.dataobjects.Project"
> > ..>
> >
> >
> >
> >
> >
> >
> >
> >
> >The query restrictor would get an access to the already existing
> >Query and can add or remove terms from it.
> >
> >In any case, there is still an issue of how to pass dynamic
> >parameters for query restriction at runtime. Any other options besides
metadata
> manipulation?
> >
> >It would be nice to do something like this:
> >
> >Engineer e = < get engineer from data store >
> >e.setProjectCollectionConstraints( firstDate, secondDate );
> >Iterator it = e.getProjects();
> >while( it.hasNext() ) {
> > ...
> >}
> >
> >In this case the restrictor callback or query builder would have
> >to have an access to the instance of the object that 'originates'
> >the query. Any ideas?
> >
> >--Bill.
> >
> >
> >
> >
> >>Here's an idea on the collection restriction discussion. How about
something
> >>like this:
> >>
> >>/**
> >> * Interface implemented by classes which are used to create a custom
> >> * query for the contents of a
> >>collection property, when the usual
> >> * fk/pk approach is insufficient.
> >> */
> >>interface org.apache.ojb.broker.query.QueryBuilder
> >>/** Build the query to retrieve the specified collection property
> >>*/
> >>Query buildQuery(Object obj, ClassDescriptor cld,
CollectionDescriptor
> cds);
> >>}
> >>
> >>class PersistenceBrokerImpl {
> >>private void retrieveCollection(...) {
> >>if (cds.getQueryBuilder()
> >>!= null)
> >>{
> >>fkQuery = cds.getQueryBuilder.buildQuery(obj, cld, cls);
> >>}
> >>else if (cds.isMtoNRelation())
> >>{
> >>fkQuery = getMtoN
