You are viewing a plain text version of this content. The canonical link for it is here.
Posted to ojb-user@db.apache.org by Jakob Braeuchi <jb...@gmx.ch> on 2005/01/04 22:26:00 UTC
Re: FEATURE REQUEST : specify foreign-key-attribute to use with c
olle ction descriptors instead of using primary of container class
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:jbraeuchi@gmx.ch]
> 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: ojb-user-unsubscribe@db.apache.org
>>For additional commands, e-mail: ojb-user-help@db.apache.org
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
> For additional commands, e-mail: ojb-user-help@db.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
> For additional commands, e-mail: ojb-user-help@db.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-user-help@db.apache.org
Re: FEATURE REQUEST : specify foreign-key-attribute to use with c
olle ction descriptors instead of using primary of container class
Posted by Jakob Braeuchi <jb...@gmx.ch>.
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:jbraeuchi@gmx.ch]
>> 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: ojb-user-unsubscribe@db.apache.org
>>> For additional commands, e-mail: ojb-user-help@db.apache.org
>>>
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
>> For additional commands, e-mail: ojb-user-help@db.apache.org
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
>> For additional commands, e-mail: ojb-user-help@db.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
> For additional commands, e-mail: ojb-user-help@db.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-user-help@db.apache.org