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 "Janssen, Roger" <Ro...@ibanx.nl> on 2004/12/12 21:37:16 UTC
RE: FEATURE REQUEST : specify foreign-key-attribute to use with c
olle ction descriptors instead of using primary of container class
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
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
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'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