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]
