RE: Problem with anonymous keys in 1:n back-mapping (again)
This is not exactly my problem. I construct my Transition object myself. Like this: Transition t = new Transition(); t.setPostStatus(postStatus); t.setAction(action); t.setPreStatus(preStatus); Now I use the broker to get a ClassDescriptor for Transitions. I iterate over the primary keys (unfortunately one can not define other unique keys...) and want to read the field values to construct an Identity to be used with broker.getObjectWithIdentity. The anonymous field values of self-constructed object are null. Transition objects created (materialized) by the broker might show the correct field value. But this is not the point. I added the fields to the class and do not use the anonymous access anymore. In t.setPostStatus(status) etc. i synchronize the respective field values: postStatusName = postStatus == null? null: postStatus.getName(); I expected the AnonymousPersistentField to return postStatus == null? nul:postStatus.getName() for the anonymous field postStatusName regardless whether this object was created by ty ojb or myself. As I understand all fields can be made anonymous. But for referenced PK's it would make sense to introduce a AnonymousForeignKeyPersistentField? Thanks, Vincenz -Original Message- From: Jakob Braeuchi [mailto:[EMAIL PROTECTED] Sent: Wednesday, October 15, 2003 4:45 PM To: OJB Users List Subject: Re: Problem with anonymous keys in 1:n back-mapping (again) hi vincenz, the main difference is that you use anonymous primary-keys but this should not cause troubles. imo you'll have to materialize transition to get the fields filled. see RowReaderDefaultImpl#buildWithReflection (i set a breakpoint in AnonymousPersistentField#set to find out) hth jakob Vincenz Braun wrote: hi jakob, my problem might be a little bit different. I have tables Actions and Statutes with a string primary key. Table Transitions has three columns preStatusName, actionName, postStatusName. preStatusName and postStatusName reference to primary key of Statuses and actionName references to primary key of Actions. Table Transitions has a compound primary key (preStatusName, actionName, postStatusName). class-descriptor class=Transition table=Transitions field-descriptor name=preStatusName column=preStatusName primaryKey=true access=anonymous/ field-descriptor name=actionName column=actionName primaryKey=true access=anonymous/ field-descriptor name=postStatusName column=postStatusName primaryKey=true access=anonymous/ reference-descriptor name=preStatus class-ref=Status foreign-key field-ref=preStatusName/ /reference-descriptor reference-descriptor name=action class-ref=Action foreign-key field-ref=actionName/ /reference-descriptor reference-descriptor name=postStatus class-ref=Status foreign-key field-ref=postStatusName/ /reference-descriptor /class-descriptor I use the PB Api only to get meta information of a class (PrimaryKeys etc.) to build up a query for that class depending on the values of the primary key (e.g. to look up the class). When I use field.get(transition) I get null for the anonymous fields. When I remove the access type anonymous everything is fine. The transition object might not be constructed by the PB e.g. I have Transition t = new Transition(); t.setPostStatus(postStatus); t.setAction(action); t.setPreStatus(preStatus); persistentField.get(t) returns null where persistentField is one of the three declared fields with anonymous access. Is postStatusName anonymously mapped to postStatus.name? Or has the transition object to be materialized from the PB to return the correct field values? Thank you very much, Vincenz -Original Message- From: Jakob Braeuchi [mailto:[EMAIL PROTECTED] Sent: Monday, October 13, 2003 8:42 PM To: OJB Users List Subject: Re: Problem with anonymous keys in 1:n back-mapping (again) hi vincent, just to make it clear the attribute 'userId' is null because access is anonymous and no attribute is required in your class. the attribute 'user' should contain an instance of object User. i do have a testcase for this feature and it works. class-descriptor class=brj.ojb.Person table=tabPerson field-descriptor id=1 name=id column=id jdbc-type=INTEGER primarykey=true autoincrement=true conversion=brj.ojb.TestFieldConversion / ... collection-descriptor name=konti collection-class=org.apache.ojb.broker.util.collections.Manag eableArrayList orderby=saldo sort=ASC element-class-ref=brj.ojb.Konto proxy=true refresh=true auto-retrieve=true auto-update=true auto-delete=true
Re: Problem with anonymous keys in 1:n back-mapping (again)
hi vincenz, is this problem solved now ? jakob Vincenz Braun wrote: hi jakob, my problem might be a little bit different. I have tables Actions and Statutes with a string primary key. Table Transitions has three columns preStatusName, actionName, postStatusName. preStatusName and postStatusName reference to primary key of Statuses and actionName references to primary key of Actions. Table Transitions has a compound primary key (preStatusName, actionName, postStatusName). class-descriptor class=Transition table=Transitions field-descriptor name=preStatusName column=preStatusName primaryKey=true access=anonymous/ field-descriptor name=actionName column=actionName primaryKey=true access=anonymous/ field-descriptor name=postStatusName column=postStatusName primaryKey=true access=anonymous/ reference-descriptor name=preStatus class-ref=Status foreign-key field-ref=preStatusName/ /reference-descriptor reference-descriptor name=action class-ref=Action foreign-key field-ref=actionName/ /reference-descriptor reference-descriptor name=postStatus class-ref=Status foreign-key field-ref=postStatusName/ /reference-descriptor /class-descriptor I use the PB Api only to get meta information of a class (PrimaryKeys etc.) to build up a query for that class depending on the values of the primary key (e.g. to look up the class). When I use field.get(transition) I get null for the anonymous fields. When I remove the access type anonymous everything is fine. The transition object might not be constructed by the PB e.g. I have Transition t = new Transition(); t.setPostStatus(postStatus); t.setAction(action); t.setPreStatus(preStatus); persistentField.get(t) returns null where persistentField is one of the three declared fields with anonymous access. Is postStatusName anonymously mapped to postStatus.name? Or has the transition object to be materialized from the PB to return the correct field values? Thank you very much, Vincenz -Original Message- From: Jakob Braeuchi [mailto:[EMAIL PROTECTED] Sent: Monday, October 13, 2003 8:42 PM To: OJB Users List Subject: Re: Problem with anonymous keys in 1:n back-mapping (again) hi vincent, just to make it clear the attribute 'userId' is null because access is anonymous and no attribute is required in your class. the attribute 'user' should contain an instance of object User. i do have a testcase for this feature and it works. class-descriptor class=brj.ojb.Person table=tabPerson field-descriptor id=1 name=id column=id jdbc-type=INTEGER primarykey=true autoincrement=true conversion=brj.ojb.TestFieldConversion / ... collection-descriptor name=konti collection-class=org.apache.ojb.broker.util.collections.Manag eableArrayList orderby=saldo sort=ASC element-class-ref=brj.ojb.Konto proxy=true refresh=true auto-retrieve=true auto-update=true auto-delete=true inverse-foreignkey field-ref=idPerson/ class-descriptor class=brj.ojb.Konto table=tabKonto field-descriptor id=1 name=idKto column=id jdbc-type=INTEGER primarykey=true autoincrement=true / field-descriptor id=2 name=idPerson column=idPerson jdbc-type=INTEGER access=anonymous / ... reference-descriptor name=inhaber class-ref=brj.ojb.Person foreignkey field-ref=idPerson/ /reference-descriptor hth jakob Vincenz Braun wrote: Hello, I have the same problem described earlier in this list by Gerhard Grosse. What is the status of this issue? Is someone working on this or has at least committed a bug report? I queried scarab and did not find a matching issue, yet. Any help greatly appreciated. Vincenz original post from Gerhard Grosse: tried to implement a bi-directional 1:n association between classes User and UserRole with an anonymous key in UserRole: class-descriptor class=de.lexcom.noralinkojb.model.User table=OJB.USERS field-descriptor name=id column=ID jdbc-type=INTEGER primarykey=true autoincrement=true/ collection-descriptor name=roles element-class-ref=de.lexcom.noralinkojb.model.UserRole auto-retrieve=true auto-update=true auto-delete=true inverse-foreignkey field-ref=userId/ /collection-descriptor /class-descriptor class-descriptor class=de.lexcom.noralinkojb.model.UserRole table=OJB.USER_ROLES field-descriptor name=userId column=USER_ID jdbc-type=INTEGER primarykey=true access
Re: Problem with anonymous keys in 1:n back-mapping (again)
hi vincenz, the main difference is that you use anonymous primary-keys but this should not cause troubles. imo you'll have to materialize transition to get the fields filled. see RowReaderDefaultImpl#buildWithReflection (i set a breakpoint in AnonymousPersistentField#set to find out) hth jakob Vincenz Braun wrote: hi jakob, my problem might be a little bit different. I have tables Actions and Statutes with a string primary key. Table Transitions has three columns preStatusName, actionName, postStatusName. preStatusName and postStatusName reference to primary key of Statuses and actionName references to primary key of Actions. Table Transitions has a compound primary key (preStatusName, actionName, postStatusName). class-descriptor class=Transition table=Transitions field-descriptor name=preStatusName column=preStatusName primaryKey=true access=anonymous/ field-descriptor name=actionName column=actionName primaryKey=true access=anonymous/ field-descriptor name=postStatusName column=postStatusName primaryKey=true access=anonymous/ reference-descriptor name=preStatus class-ref=Status foreign-key field-ref=preStatusName/ /reference-descriptor reference-descriptor name=action class-ref=Action foreign-key field-ref=actionName/ /reference-descriptor reference-descriptor name=postStatus class-ref=Status foreign-key field-ref=postStatusName/ /reference-descriptor /class-descriptor I use the PB Api only to get meta information of a class (PrimaryKeys etc.) to build up a query for that class depending on the values of the primary key (e.g. to look up the class). When I use field.get(transition) I get null for the anonymous fields. When I remove the access type anonymous everything is fine. The transition object might not be constructed by the PB e.g. I have Transition t = new Transition(); t.setPostStatus(postStatus); t.setAction(action); t.setPreStatus(preStatus); persistentField.get(t) returns null where persistentField is one of the three declared fields with anonymous access. Is postStatusName anonymously mapped to postStatus.name? Or has the transition object to be materialized from the PB to return the correct field values? Thank you very much, Vincenz -Original Message- From: Jakob Braeuchi [mailto:[EMAIL PROTECTED] Sent: Monday, October 13, 2003 8:42 PM To: OJB Users List Subject: Re: Problem with anonymous keys in 1:n back-mapping (again) hi vincent, just to make it clear the attribute 'userId' is null because access is anonymous and no attribute is required in your class. the attribute 'user' should contain an instance of object User. i do have a testcase for this feature and it works. class-descriptor class=brj.ojb.Person table=tabPerson field-descriptor id=1 name=id column=id jdbc-type=INTEGER primarykey=true autoincrement=true conversion=brj.ojb.TestFieldConversion / ... collection-descriptor name=konti collection-class=org.apache.ojb.broker.util.collections.Manag eableArrayList orderby=saldo sort=ASC element-class-ref=brj.ojb.Konto proxy=true refresh=true auto-retrieve=true auto-update=true auto-delete=true inverse-foreignkey field-ref=idPerson/ class-descriptor class=brj.ojb.Konto table=tabKonto field-descriptor id=1 name=idKto column=id jdbc-type=INTEGER primarykey=true autoincrement=true / field-descriptor id=2 name=idPerson column=idPerson jdbc-type=INTEGER access=anonymous / ... reference-descriptor name=inhaber class-ref=brj.ojb.Person foreignkey field-ref=idPerson/ /reference-descriptor hth jakob Vincenz Braun wrote: Hello, I have the same problem described earlier in this list by Gerhard Grosse. What is the status of this issue? Is someone working on this or has at least committed a bug report? I queried scarab and did not find a matching issue, yet. Any help greatly appreciated. Vincenz original post from Gerhard Grosse: tried to implement a bi-directional 1:n association between classes User and UserRole with an anonymous key in UserRole: class-descriptor class=de.lexcom.noralinkojb.model.User table=OJB.USERS field-descriptor name=id column=ID jdbc-type=INTEGER primarykey=true autoincrement=true/ collection-descriptor name=roles element-class-ref=de.lexcom.noralinkojb.model.UserRole auto-retrieve=true auto-update=true auto-delete=true inverse-foreignkey field-ref=userId/ /collection-descriptor /class-descriptor class
Re: Problem with anonymous keys in 1:n back-mapping (again)
Hi Jakob, It was the attribute 'user' that was null, when I made 'userId' anonymous, and the problem was quite reproducible. I didn't follow up on this because I moved to the ODMG API, where the problem hasn't occurred so far. Does your testcase work when setting proxy=false in the collection descriptor? Unfortunatelly I don't have the original code any more to do more research on this problem. Best regards, Gerhard Jakob Braeuchi [EMAIL PROTECTED] 13.10.2003 20:42 Bitte antworten an OJB Users List An: OJB Users List [EMAIL PROTECTED] Kopie: Thema: Re: Problem with anonymous keys in 1:n back-mapping (again) hi vincent, just to make it clear the attribute 'userId' is null because access is anonymous and no attribute is required in your class. the attribute 'user' should contain an instance of object User. i do have a testcase for this feature and it works. class-descriptor class=brj.ojb.Person table=tabPerson field-descriptor id=1 name=id column=id jdbc-type=INTEGER primarykey=true autoincrement=true conversion=brj.ojb.TestFieldConversion / ... collection-descriptor name=konti collection-class=org.apache.ojb.broker.util.collections.ManageableArrayList orderby=saldo sort=ASC element-class-ref=brj.ojb.Konto proxy=true refresh=true auto-retrieve=true auto-update=true auto-delete=true inverse-foreignkey field-ref=idPerson/ class-descriptor class=brj.ojb.Konto table=tabKonto field-descriptor id=1 name=idKto column=id jdbc-type=INTEGER primarykey=true autoincrement=true / field-descriptor id=2 name=idPerson column=idPerson jdbc-type=INTEGER access=anonymous / ... reference-descriptor name=inhaber class-ref=brj.ojb.Person foreignkey field-ref=idPerson/ /reference-descriptor hth jakob Vincenz Braun wrote: Hello, I have the same problem described earlier in this list by Gerhard Grosse. What is the status of this issue? Is someone working on this or has at least committed a bug report? I queried scarab and did not find a matching issue, yet. Any help greatly appreciated. Vincenz original post from Gerhard Grosse: tried to implement a bi-directional 1:n association between classes User and UserRole with an anonymous key in UserRole: class-descriptor class=de.lexcom.noralinkojb.model.User table=OJB.USERS field-descriptor name=id column=ID jdbc-type=INTEGER primarykey=true autoincrement=true/ collection-descriptor name=roles element-class-ref=de.lexcom.noralinkojb.model.UserRole auto-retrieve=true auto-update=true auto-delete=true inverse-foreignkey field-ref=userId/ /collection-descriptor /class-descriptor class-descriptor class=de.lexcom.noralinkojb.model.UserRole table=OJB.USER_ROLES field-descriptor name=userId column=USER_ID jdbc-type=INTEGER primarykey=true access=anonymous/ field-descriptor name=role column=ROLE jdbc-type=INTEGER primarykey=true/ reference-descriptor name=user class-ref=de.lexcom.noralinkojb.model.User auto-retrieve=true foreignkey field-ref=userId/ /reference-descriptor /class-descriptor When I now load a User object which has associated UserRoles, the user attribute of all UserRoles is null. The problem disappears when I make userId a normal attribute of UserRole. Is this a known limitation of anonymous keys, is it a bug or am I doing something wrong here? - 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]
Re: Problem with anonymous keys in 1:n back-mapping (again)
hi gerhard, yup, it also works with proxy=false. do you use the latest from repository ? jakob [EMAIL PROTECTED] wrote: Hi Jakob, It was the attribute 'user' that was null, when I made 'userId' anonymous, and the problem was quite reproducible. I didn't follow up on this because I moved to the ODMG API, where the problem hasn't occurred so far. Does your testcase work when setting proxy=false in the collection descriptor? Unfortunatelly I don't have the original code any more to do more research on this problem. Best regards, Gerhard Jakob Braeuchi [EMAIL PROTECTED] 13.10.2003 20:42 Bitte antworten an OJB Users List An: OJB Users List [EMAIL PROTECTED] Kopie: Thema: Re: Problem with anonymous keys in 1:n back-mapping (again) hi vincent, just to make it clear the attribute 'userId' is null because access is anonymous and no attribute is required in your class. the attribute 'user' should contain an instance of object User. i do have a testcase for this feature and it works. class-descriptor class=brj.ojb.Person table=tabPerson field-descriptor id=1 name=id column=id jdbc-type=INTEGER primarykey=true autoincrement=true conversion=brj.ojb.TestFieldConversion / ... collection-descriptor name=konti collection-class=org.apache.ojb.broker.util.collections.ManageableArrayList orderby=saldo sort=ASC element-class-ref=brj.ojb.Konto proxy=true refresh=true auto-retrieve=true auto-update=true auto-delete=true inverse-foreignkey field-ref=idPerson/ class-descriptor class=brj.ojb.Konto table=tabKonto field-descriptor id=1 name=idKto column=id jdbc-type=INTEGER primarykey=true autoincrement=true / field-descriptor id=2 name=idPerson column=idPerson jdbc-type=INTEGER access=anonymous / ... reference-descriptor name=inhaber class-ref=brj.ojb.Person foreignkey field-ref=idPerson/ /reference-descriptor hth jakob Vincenz Braun wrote: Hello, I have the same problem described earlier in this list by Gerhard Grosse. What is the status of this issue? Is someone working on this or has at least committed a bug report? I queried scarab and did not find a matching issue, yet. Any help greatly appreciated. Vincenz original post from Gerhard Grosse: tried to implement a bi-directional 1:n association between classes User and UserRole with an anonymous key in UserRole: class-descriptor class=de.lexcom.noralinkojb.model.User table=OJB.USERS field-descriptor name=id column=ID jdbc-type=INTEGER primarykey=true autoincrement=true/ collection-descriptor name=roles element-class-ref=de.lexcom.noralinkojb.model.UserRole auto-retrieve=true auto-update=true auto-delete=true inverse-foreignkey field-ref=userId/ /collection-descriptor /class-descriptor class-descriptor class=de.lexcom.noralinkojb.model.UserRole table=OJB.USER_ROLES field-descriptor name=userId column=USER_ID jdbc-type=INTEGER primarykey=true access=anonymous/ field-descriptor name=role column=ROLE jdbc-type=INTEGER primarykey=true/ reference-descriptor name=user class-ref=de.lexcom.noralinkojb.model.User auto-retrieve=true foreignkey field-ref=userId/ /reference-descriptor /class-descriptor When I now load a User object which has associated UserRoles, the user attribute of all UserRoles is null. The problem disappears when I make userId a normal attribute of UserRole. Is this a known limitation of anonymous keys, is it a bug or am I doing something wrong here? - 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]
Antwort: Re: Problem with anonymous keys in 1:n back-mapping (again)
Hi Jakob, At the time I had the problem, I was using RC4. Now I use CVS HEAD (and ODMG API). I'll see if I can find the old code and reproduce the problem with the lastest version of OJB. Gerhard Jakob Braeuchi [EMAIL PROTECTED] 14.10.2003 14:29 Bitte antworten an OJB Users List An: OJB Users List [EMAIL PROTECTED] Kopie: Thema: Re: Problem with anonymous keys in 1:n back-mapping (again) hi gerhard, yup, it also works with proxy=false. do you use the latest from repository ? jakob [EMAIL PROTECTED] wrote: Hi Jakob, It was the attribute 'user' that was null, when I made 'userId' anonymous, and the problem was quite reproducible. I didn't follow up on this because I moved to the ODMG API, where the problem hasn't occurred so far. Does your testcase work when setting proxy=false in the collection descriptor? Unfortunatelly I don't have the original code any more to do more research on this problem. Best regards, Gerhard Jakob Braeuchi [EMAIL PROTECTED] 13.10.2003 20:42 Bitte antworten an OJB Users List An: OJB Users List [EMAIL PROTECTED] Kopie: Thema: Re: Problem with anonymous keys in 1:n back-mapping (again) hi vincent, just to make it clear the attribute 'userId' is null because access is anonymous and no attribute is required in your class. the attribute 'user' should contain an instance of object User. i do have a testcase for this feature and it works. class-descriptor class=brj.ojb.Person table=tabPerson field-descriptor id=1 name=id column=id jdbc-type=INTEGER primarykey=true autoincrement=true conversion=brj.ojb.TestFieldConversion / ... collection-descriptor name=konti collection-class=org.apache.ojb.broker.util.collections.ManageableArrayList orderby=saldo sort=ASC element-class-ref=brj.ojb.Konto proxy=true refresh=true auto-retrieve=true auto-update=true auto-delete=true inverse-foreignkey field-ref=idPerson/ class-descriptor class=brj.ojb.Konto table=tabKonto field-descriptor id=1 name=idKto column=id jdbc-type=INTEGER primarykey=true autoincrement=true / field-descriptor id=2 name=idPerson column=idPerson jdbc-type=INTEGER access=anonymous / ... reference-descriptor name=inhaber class-ref=brj.ojb.Person foreignkey field-ref=idPerson/ /reference-descriptor hth jakob Vincenz Braun wrote: Hello, I have the same problem described earlier in this list by Gerhard Grosse. What is the status of this issue? Is someone working on this or has at least committed a bug report? I queried scarab and did not find a matching issue, yet. Any help greatly appreciated. Vincenz original post from Gerhard Grosse: tried to implement a bi-directional 1:n association between classes User and UserRole with an anonymous key in UserRole: class-descriptor class=de.lexcom.noralinkojb.model.User table=OJB.USERS field-descriptor name=id column=ID jdbc-type=INTEGER primarykey=true autoincrement=true/ collection-descriptor name=roles element-class-ref=de.lexcom.noralinkojb.model.UserRole auto-retrieve=true auto-update=true auto-delete=true inverse-foreignkey field-ref=userId/ /collection-descriptor /class-descriptor class-descriptor class=de.lexcom.noralinkojb.model.UserRole table=OJB.USER_ROLES field-descriptor name=userId column=USER_ID jdbc-type=INTEGER primarykey=true access=anonymous/ field-descriptor name=role column=ROLE jdbc-type=INTEGER primarykey=true/ reference-descriptor name=user class-ref=de.lexcom.noralinkojb.model.User auto-retrieve=true foreignkey field-ref=userId/ /reference-descriptor /class-descriptor When I now load a User object which has associated UserRoles, the user attribute of all UserRoles is null. The problem disappears when I make userId a normal attribute of UserRole. Is this a known limitation of anonymous keys, is it a bug or am I doing something wrong here
RE: Problem with anonymous keys in 1:n back-mapping (again)
hi jakob, my problem might be a little bit different. I have tables Actions and Statutes with a string primary key. Table Transitions has three columns preStatusName, actionName, postStatusName. preStatusName and postStatusName reference to primary key of Statuses and actionName references to primary key of Actions. Table Transitions has a compound primary key (preStatusName, actionName, postStatusName). class-descriptor class=Transition table=Transitions field-descriptor name=preStatusName column=preStatusName primaryKey=true access=anonymous/ field-descriptor name=actionName column=actionName primaryKey=true access=anonymous/ field-descriptor name=postStatusName column=postStatusName primaryKey=true access=anonymous/ reference-descriptor name=preStatus class-ref=Status foreign-key field-ref=preStatusName/ /reference-descriptor reference-descriptor name=action class-ref=Action foreign-key field-ref=actionName/ /reference-descriptor reference-descriptor name=postStatus class-ref=Status foreign-key field-ref=postStatusName/ /reference-descriptor /class-descriptor I use the PB Api only to get meta information of a class (PrimaryKeys etc.) to build up a query for that class depending on the values of the primary key (e.g. to look up the class). When I use field.get(transition) I get null for the anonymous fields. When I remove the access type anonymous everything is fine. The transition object might not be constructed by the PB e.g. I have Transition t = new Transition(); t.setPostStatus(postStatus); t.setAction(action); t.setPreStatus(preStatus); persistentField.get(t) returns null where persistentField is one of the three declared fields with anonymous access. Is postStatusName anonymously mapped to postStatus.name? Or has the transition object to be materialized from the PB to return the correct field values? Thank you very much, Vincenz -Original Message- From: Jakob Braeuchi [mailto:[EMAIL PROTECTED] Sent: Monday, October 13, 2003 8:42 PM To: OJB Users List Subject: Re: Problem with anonymous keys in 1:n back-mapping (again) hi vincent, just to make it clear the attribute 'userId' is null because access is anonymous and no attribute is required in your class. the attribute 'user' should contain an instance of object User. i do have a testcase for this feature and it works. class-descriptor class=brj.ojb.Person table=tabPerson field-descriptor id=1 name=id column=id jdbc-type=INTEGER primarykey=true autoincrement=true conversion=brj.ojb.TestFieldConversion / ... collection-descriptor name=konti collection-class=org.apache.ojb.broker.util.collections.Manag eableArrayList orderby=saldo sort=ASC element-class-ref=brj.ojb.Konto proxy=true refresh=true auto-retrieve=true auto-update=true auto-delete=true inverse-foreignkey field-ref=idPerson/ class-descriptor class=brj.ojb.Konto table=tabKonto field-descriptor id=1 name=idKto column=id jdbc-type=INTEGER primarykey=true autoincrement=true / field-descriptor id=2 name=idPerson column=idPerson jdbc-type=INTEGER access=anonymous / ... reference-descriptor name=inhaber class-ref=brj.ojb.Person foreignkey field-ref=idPerson/ /reference-descriptor hth jakob Vincenz Braun wrote: Hello, I have the same problem described earlier in this list by Gerhard Grosse. What is the status of this issue? Is someone working on this or has at least committed a bug report? I queried scarab and did not find a matching issue, yet. Any help greatly appreciated. Vincenz original post from Gerhard Grosse: tried to implement a bi-directional 1:n association between classes User and UserRole with an anonymous key in UserRole: class-descriptor class=de.lexcom.noralinkojb.model.User table=OJB.USERS field-descriptor name=id column=ID jdbc-type=INTEGER primarykey=true autoincrement=true/ collection-descriptor name=roles element-class-ref=de.lexcom.noralinkojb.model.UserRole auto-retrieve=true auto-update=true auto-delete=true inverse-foreignkey field-ref=userId/ /collection-descriptor /class-descriptor class-descriptor class=de.lexcom.noralinkojb.model.UserRole table
Re: Problem with anonymous keys in 1:n back-mapping (again)
I am looking into it. I presume you are using the PB api based on the auto-* being set. I have an almost identical mapping that works fine, but am using the OTM... I'll play with it against the PB tonight with the auto-* set they way you do and see what I can find. If there is no bug open on it... I encourage you to open one ;-) -Brian On Saturday, October 11, 2003, at 03:41 PM, Vincenz Braun wrote: Hello, I have the same problem described earlier in this list by Gerhard Grosse. What is the status of this issue? Is someone working on this or has at least committed a bug report? I queried scarab and did not find a matching issue, yet. Any help greatly appreciated. Vincenz original post from Gerhard Grosse: tried to implement a bi-directional 1:n association between classes User and UserRole with an anonymous key in UserRole: class-descriptor class=de.lexcom.noralinkojb.model.User table=OJB.USERS field-descriptor name=id column=ID jdbc-type=INTEGER primarykey=true autoincrement=true/ collection-descriptor name=roles element-class-ref=de.lexcom.noralinkojb.model.UserRole auto-retrieve=true auto-update=true auto-delete=true inverse-foreignkey field-ref=userId/ /collection-descriptor /class-descriptor class-descriptor class=de.lexcom.noralinkojb.model.UserRole table=OJB.USER_ROLES field-descriptor name=userId column=USER_ID jdbc-type=INTEGER primarykey=true access=anonymous/ field-descriptor name=role column=ROLE jdbc-type=INTEGER primarykey=true/ reference-descriptor name=user class-ref=de.lexcom.noralinkojb.model.User auto-retrieve=true foreignkey field-ref=userId/ /reference-descriptor /class-descriptor When I now load a User object which has associated UserRoles, the user attribute of all UserRoles is null. The problem disappears when I make userId a normal attribute of UserRole. Is this a known limitation of anonymous keys, is it a bug or am I doing something wrong here? - 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]
Re: Problem with anonymous keys in 1:n back-mapping (again)
hi vincent, just to make it clear the attribute 'userId' is null because access is anonymous and no attribute is required in your class. the attribute 'user' should contain an instance of object User. i do have a testcase for this feature and it works. class-descriptor class=brj.ojb.Person table=tabPerson field-descriptor id=1 name=id column=id jdbc-type=INTEGER primarykey=true autoincrement=true conversion=brj.ojb.TestFieldConversion / ... collection-descriptor name=konti collection-class=org.apache.ojb.broker.util.collections.ManageableArrayList orderby=saldo sort=ASC element-class-ref=brj.ojb.Konto proxy=true refresh=true auto-retrieve=true auto-update=true auto-delete=true inverse-foreignkey field-ref=idPerson/ class-descriptor class=brj.ojb.Konto table=tabKonto field-descriptor id=1 name=idKto column=id jdbc-type=INTEGER primarykey=true autoincrement=true / field-descriptor id=2 name=idPerson column=idPerson jdbc-type=INTEGER access=anonymous / ... reference-descriptor name=inhaber class-ref=brj.ojb.Person foreignkey field-ref=idPerson/ /reference-descriptor hth jakob Vincenz Braun wrote: Hello, I have the same problem described earlier in this list by Gerhard Grosse. What is the status of this issue? Is someone working on this or has at least committed a bug report? I queried scarab and did not find a matching issue, yet. Any help greatly appreciated. Vincenz original post from Gerhard Grosse: tried to implement a bi-directional 1:n association between classes User and UserRole with an anonymous key in UserRole: class-descriptor class=de.lexcom.noralinkojb.model.User table=OJB.USERS field-descriptor name=id column=ID jdbc-type=INTEGER primarykey=true autoincrement=true/ collection-descriptor name=roles element-class-ref=de.lexcom.noralinkojb.model.UserRole auto-retrieve=true auto-update=true auto-delete=true inverse-foreignkey field-ref=userId/ /collection-descriptor /class-descriptor class-descriptor class=de.lexcom.noralinkojb.model.UserRole table=OJB.USER_ROLES field-descriptor name=userId column=USER_ID jdbc-type=INTEGER primarykey=true access=anonymous/ field-descriptor name=role column=ROLE jdbc-type=INTEGER primarykey=true/ reference-descriptor name=user class-ref=de.lexcom.noralinkojb.model.User auto-retrieve=true foreignkey field-ref=userId/ /reference-descriptor /class-descriptor When I now load a User object which has associated UserRoles, the user attribute of all UserRoles is null. The problem disappears when I make userId a normal attribute of UserRole. Is this a known limitation of anonymous keys, is it a bug or am I doing something wrong here? - 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]
