Hi, That's okay with me. In my case, it concerns all kinds of relations, i just gave an example of one of them, so if this feature becomes available for all relationships, i will be a very happy man.
I refactored some of the code in our app to workaround the performance issue i had, so the heat is somewhat off for me on needing this thing to be solved real quick, so if it's in 1.1 release, that's fine. Another question i have, is one that i have seen popping up sometimes (recently by others) on the list, is the usage of path expressions for values in criteria, that way it kind of allows us to define our own join criteria. It opens up a lot of possibilities for querying. My guess is that it is complicated to implement this, but are there any thoughts on this issue? Thanx for the quick response and the plans to implement the suggested feature. Roger Janssen iBanx -----Original Message----- From: Jakob Braeuchi [mailto:[EMAIL PROTECTED] Sent: Sunday, December 12, 2004 6:11 PM To: OJB Users List Subject: Re: FEATURE REQUEST : specify foreign-key-attribute to use with colle ction descriptors instead of using primary of container class hi roger, when considering this feature we should not only focus on 1:n collections but on any relationships. i'd prefer to introduce feature for ojb 1.1 an not try to integrate it into 1.0.x wdyt ? jakob Jakob Braeuchi schrieb: > hi roger, > > imo this feature could be useful in some real life scenarios; even > without an intermediate class like Acl in your example. > > but i'd prefer to extend the inverse-foreignkey (called "referencing" in > the following snippet, but this is just a temp name). if the referencing > attribute is missing we assume the pk of the element-class-ref is used. > > <class-descriptor class="ibanx.doc.Document" > ..... > ..... > <collection-descriptor name="permissions" > element-class-ref="ibanx.security.Permission" > ... > <inverse-foreignkey field-ref="aclId" > referencing="docAclId"/> > </collection-descriptor> > </class-descriptor> > > jakob > > Janssen, Roger schrieb: > >> Hi guys, i've got a question. >> >> I am using 1.0-rc6. >> >> Currently, using a collection descriptor, you specify the >> inverse-foreignkey >> attribute on the items of the collection, and these attributes are >> matched >> with the value of the primary key of the object that contains the >> collection. >> >> However, consider the following (simplified) situation: >> >> >> Document Acl Permission >> id -----------> id <---| id >> ... | ... | ... >> ... | |------------ aclId >> aclId -----| ... >> ... >> >> >> I have an class document, containing a foreignkey reference to a class >> Acl, >> and i have a class permission containing a foreignkey reference to an >> acl. >> The class document has an attribute acl populated by OJB by using a >> reference descriptor. >> The class Acl has an collection attribute permissions collected by OJB >> using >> a collection descriptor. >> >> When a query for documents, using permission criteria, the query becomes >> complex, OJB joins document, acl and permission, using nested objects in >> criteria like "acl.permission.value" on a document instances. >> In plain sql, we could query joining document and permission on >> document.aclid = permission.aclid. Using OJB, this currently is not >> possible, because i am not able to define a >> collection descriptor on document mapping permissions. >> >> This would become possible, if we were able to specify a >> foreignkey-attribute on a collection descriptor. Example: >> >> <class-descriptor class="ibanx.doc.Document" >> ..... >> ..... >> <collection-descriptor name="permissions" >> element-class-ref="ibanx.security.Permission" >> auto-retrieve="false" auto-update="false" >> auto-delete="false"> >> <inverse-foreignkey field-ref="aclId"/> >> <foreignkey field-ref="aclId"/> >> </collection-descriptor> >> </class-descriptor> >> >> This collection descriptor defines a collection of Permissions on the >> document class, using aclId of document as foreignkey, matching >> it with aclid of Permission. I can use this descriptor for querying >> purposes, and now OJB only can to join the document and permission tables >> using nested objects in criteria like "permission.value" on a document >> instance. >> >> Within our app, this kind of join pattern appears several times, >> sometimes >> even several times within one query, needless to say that we are >> experiencing some performance issues when the rather more complex queries >> are being executed, to a point were the application becomes not usable. >> >> I tried to look what i had to change within OJB source code myself, so i >> could deliver a patch, but i noticed the complexity of the interaction >> between CollectionDescriptor, XMLHandlers and SQL statement >> generators. So i >> do not really know were to start. >> >> So my question is, do you think this would be a usefull feature, and >> might >> it be implemented in the future. >> If it is obvious what needs to be changed, can onyone point me in the >> right >> direction, so i can patch the 1.0-rc6 version we are still using. >> >> thanx, >> >> Roger Janssen >> iBanx >> > > --------------------------------------------------------------------- > 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]
