hi roger,
i just commited the changes to support this feature. please check it out.
jakob
Jakob Braeuchi schrieb:
hi roger,
i'm currently working on a solution non-pk fields in collection- and reference-descriptors. these fields are defined in target-field-ref:
<inverse-foreignkey field-ref="productGroupName" target-field-ref="groupName"/> <foreignkey field-ref="productGroupName" target-field-ref="groupName"/>
when target-field-ref is missing ojb will use the pk of the referenced class.
the implementation was quite tricky because it affects metadata, joins and prefetching. it needs further testing, but i hope i can commit it within a week or two ;)
this feature is currently supported for 1:1 and 1:n relationships. i'll try to support m:n later.
the following snippet from repository_junit shows the definition for some test-classes.
<class-descriptor class="org.apache.ojb.broker.NoPkReferenceTest$Article_2" table="Artikel_2" > <field-descriptor name="articleId" column="Artikel_Nr" jdbc-type="INTEGER" primarykey="true" autoincrement="true" /> <field-descriptor name="articleName" column="Artikelname" jdbc-type="VARCHAR" /> <field-descriptor name="supplierId" column="Lieferanten_Nr" jdbc-type="INTEGER" /> <field-descriptor name="productGroupName" column="Kategorie_Name" jdbc-type="VARCHAR" /> ... <reference-descriptor name="productGroup"
class-ref="org.apache.ojb.broker.NoPkReferenceTest$ProductGroup_2"
>
<foreignkey field-ref="productGroupName" target-field-ref="groupName"/>
</reference-descriptor>
</class-descriptor>
<class-descriptor class="org.apache.ojb.broker.NoPkReferenceTest$ProductGroup_2" table="Kategorien_2" > <field-descriptor name="groupId" column="Kategorie_Nr" jdbc-type="INTEGER" primarykey="true" autoincrement="true" /> <field-descriptor name="groupName" column="Kategorie_Name" jdbc-type="VARCHAR" /> <field-descriptor name="description" column="Beschreibung" jdbc-type="VARCHAR" /> <collection-descriptor name="allArticlesInGroup"
element-class-ref="org.apache.ojb.broker.NoPkReferenceTest$Article_2" auto-retrieve="true" auto-update="true" auto-delete="false" > <inverse-foreignkey field-ref="productGroupName" target-field-ref="groupName"/> </collection-descriptor> </class-descriptor>
jakob
Janssen, Roger schrieb:
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]
--------------------------------------------------------------------- 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]
