Problem with anonymous keys in 1:n back-mapping (again)
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]
Inheritance delete problem
Hello, I've updated OJB and built to the last CVS release but still have some problem with inheritance. I've - class A and B - B extends A - to A correspond a table tA - to B correspond a table tB - between tA and tB exits an inheritance relation If I delete an entry on class B (broker.delete(b);), The entry is deleted in table tB but not on table tA! No exception is generated. In the log is reported that 2 delete query has been generated, but only the query on tB is really executed. [org.apache.ojb.broker.accesslayer.sql.SqlGeneratorDefaultImpl] DEBUG: SQL:DELETE FROM tB WHERE account_id = ? [org.apache.ojb.broker.accesslayer.sql.SqlGeneratorDefaultImpl] DEBUG: SQL:DELETE FROM tA WHERE account_id = ? Thank you - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Inheritance delete problem
Hello, I've updated OJB and built to the last CVS release but still have some problem with inheritance. I've - class A and B - B extends A - to A correspond a table tA - to B correspond a table tB - between tA and tB exits an inheritance relation If I delete an entry on class B (broker.delete(b);), The entry is deleted in table tB but not on table tA! No exception is generated. In the log is reported that 2 delete query has been generated, but only the query on tB is really executed. [org.apache.ojb.broker.accesslayer.sql.SqlGeneratorDefaultImpl] DEBUG: SQL:DELETE FROM tB WHERE account_id = ? [org.apache.ojb.broker.accesslayer.sql.SqlGeneratorDefaultImpl] DEBUG: SQL:DELETE FROM tA WHERE account_id = ? Thank you - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
NullPointerException with OQL query
I've just made mistprint in class name while typing OQL query and got NullPointerException. imho it has to be another exception instead of NullPointerException. best regards, Anton Komratov - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Auto-delete throws a referential integrity exception
Hi Class A contains a pointer to class B and a Vector with elements of class B: /** * @ojb.class * @ojb.field * name=_id * primarykey=true * autoincrement=true * jdbc-type=INTEGER * @ojb.field * name=_bId * jdbc-type=INTEGER */ public class A /** * @ojb.reference * foreignkey=_bId * auto-delete=true */ B bObj; /** * @ojb.collection * element-class-ref=B * foreignkey=_aId * auto-delete=true */ Vector bObjs; /** * @ojb.class * @ojb.field * name=_id * primarykey=true * autoincrement=true * jdbc-type=INTEGER * @ojb.field * name=_aId * jdbc-type=INTEGER */ public class B Torque creates a referential integrity for the bOjb. (Not for the collection). When I try to delete an object of type A, OJB first deletes all members of the collection, which throws an exception, since the referential integrity is broken. Is there any workaround? Thanx for any help -- Pat - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
M:N same class mapping question...
I am having problems getting a class to properly persist collections of
instances of the same class (see configs later in the email). Using the
M:N mapping seems to be the way to do this, but it isn't actually
working. If the relations exist in the database the data loads fine,
however it doesn't seem to want to persist new instances to the M:N
table. I am using the non-decomposed style M:N and have tried with the
mapping listed below, and the auto-update and auto-retrieve removed
with no change in behavior.
Anyone see what is wrong with the code below?
-- OJB Mapping ---
class-descriptor class=test.User table=USERS
field-descriptor name=id column=ID jdbc-type=INTEGER
primarykey=true autoincrement=true/
collection-descriptor name=friends
element-class-ref=org.skife.kim.model.User
indirection-table=USER_FRIEND
auto-retrieve=true
auto-update=true
fk-pointing-to-this-class column=user_id/
fk-pointing-to-element-class column=friend_id/
/collection-descriptor
/class-descriptor
-- Schema Def'n --
table name=user_friend description=M:N mapping table for user's
friends
column name=user_id primaryKey=true type=INTEGER
description=User ID /
column name=friend_id primaryKey=true type=INTEGER
description=User ID /
foreign-key foreignTable=users
reference local=user_id foreign=id/
/foreign-key
foreign-key foreignTable=users
reference local=friend_id foreign=id/
/foreign-key
/table
-- Class --
public class User
{
List friends;
}
Friends contains User instances. It seems that it loads classes
properly if they are already in the database, but is not inserting new
relations.
Danke,
Brian
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: M:N same class mapping question...
Note that the package names *do* match in the actual code - Changed the
one in place in the email and not the other =)
-Brian
On Sunday, October 12, 2003, at 10:38 PM, Brian McCallister wrote:
I am having problems getting a class to properly persist collections
of instances of the same class (see configs later in the email). Using
the M:N mapping seems to be the way to do this, but it isn't actually
working. If the relations exist in the database the data loads fine,
however it doesn't seem to want to persist new instances to the M:N
table. I am using the non-decomposed style M:N and have tried with the
mapping listed below, and the auto-update and auto-retrieve removed
with no change in behavior.
Anyone see what is wrong with the code below?
-- OJB Mapping ---
class-descriptor class=test.User table=USERS
field-descriptor name=id column=ID jdbc-type=INTEGER
primarykey=true autoincrement=true/
collection-descriptor name=friends
element-class-ref=org.skife.kim.model.User
indirection-table=USER_FRIEND
auto-retrieve=true
auto-update=true
fk-pointing-to-this-class column=user_id/
fk-pointing-to-element-class column=friend_id/
/collection-descriptor
/class-descriptor
-- Schema Def'n --
table name=user_friend description=M:N mapping table for
user's friends
column name=user_id primaryKey=true type=INTEGER
description=User ID /
column name=friend_id primaryKey=true type=INTEGER
description=User ID /
foreign-key foreignTable=users
reference local=user_id foreign=id/
/foreign-key
foreign-key foreignTable=users
reference local=friend_id foreign=id/
/foreign-key
/table
-- Class --
public class User
{
List friends;
}
Friends contains User instances. It seems that it loads classes
properly if they are already in the database, but is not inserting new
relations.
Danke,
Brian
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Problem with anonymous keys in 1:n back-mapping (again)
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]
