Armin, I don't understand why I have to declare DBAttribute's "name" field as a foreign key beside "owner" in DBObject.
I would like to allow a single DBAttribute with a given name per object, so I think DBAttribute's PK is <name, owner>. DBObject has no knowledge of the fact that DBAttribute has a "name" attribute. Besides, while "owner" refers to DBObject's PK "name", what would a second inverse foreign key point to? Alessandro > Da: Armin Waibel <[EMAIL PROTECTED]> > Data: Sat, 21 Feb 2004 11:24:11 +0100 > A: OJB Users List <[EMAIL PROTECTED]> > Oggetto: Re: Auto delete and anonymous fields > > Hi Alessandro, > > in db.DBAttribute you declare two PK fields, thus in > collection-descriptor of db.DBObject you have to declare both fields as > inverse-foreignkey to match correctly. > > I don't know if there is an additional side-effect when declaring > PK/reference fields (e.g. 'owner') anonymous. > As I said in previous mails, I don't recommend to use anonymous fields > beyond 1:1 references. > > regards, > Armin > > > Alessandro Villamaina wrote: > > Hi all, > > > > I have a problem using the auto-delete optiion in conjunction with anonymous > > fields. > > > > The classes I have to be made persistent in the DB (I'm using PostgreSQL) are > > (pseudo code): > > > > class DBObject > > private String name > > private Collection attributes > > > > class DBAttribute > > private String name > > private String value > > > > I want to set things up in order to get the DBAttributes belonging to a DBObject > > deleted when the DBObject itself gets deleted. > > > > The repository_user.xml file looks like > > > > <class-descriptor class="db.DBObject" table="DBOBJECT"> > > > > > > <field-descriptor > > name="name" > > column="NAME" > > jdbc-type="VARCHAR" > > primarykey="true" > > /> > > > > > > <collection-descriptor > > name="_attributes" > > auto-delete="true" > > auto-update="true" > > element-class-ref = "db.DBAttribute"> > > <inverse-foreignkey field-ref = "owner" /> > > </collection-descriptor> > > > > > > </class-descriptor> > > > > > > <class-descriptor > > class="db.DBAttribute" > > table="DBATTRIBUTE"> > > > > > > <field-descriptor > > name="name" > > column="NAME" > > primarykey="true" > > jdbc-type="VARCHAR" > > /> > > > > > > <field-descriptor > > name="value" > > column="VALUE" > > jdbc-type="VARCHAR" > > /> > > > > > > <field-descriptor > > name="owner" > > column="OWNER" > > jdbc-type="VARCHAR" > > primarykey="true" > > access="anonymous" > > /> > > </class-descriptor> > > > > As you can see, the OWNER column in the DBATTRIBUTE table keeps the link between > > an object and its attributes. There is no such attribute in the DBAttribute class, > > so I decided to make it an "anonymous" field, letting OJB handle it for me. > > > > The primary key of a DBATTRIBUTE record is the couple <name, owner>, since I want > > to allow a single attribute name for each object. > > > > When I save the DBObjects, everything works fine, and DBAttributes are made > > persistent along with their DBObjects. Peering into the DB tables, I can check > > that, for each record, the OWNER column contains the right reference to the owner > > object, and that is OK. > > > > When I delete one of the DBObjects, its attributes are NOT deleted. > > > > I tried to set the log4j logging level to DEBUG, and it turned out that the DELETE > > sql statements where, for each of the DBATTRIBUTE to be deleted: > > > > DELETE FROM DBATTRIBUTE WHERE name="name1" AND owner = NULL > > > > Obviously nothing is deleted from DBATTRIBUTE, since no owner is null in the table. > > The funny thing is that such DELETE statements are generated ONLY for the > > attributes that should be deleted, not for all attributes. This means that OJB > > "knows" (looking at the owner field, I guess) which attributes belong to the > > DBOBJECT and have to be deleted, but fails in assigning the right value to owner > > in the DELETE statement. > > > > Does anyone know how to solve this? > > Is this a bug or am I doing something wrong? > > > > Thanks a lot! > > > > Alessandro > > > > > > --------------------------------------------------------------------- > > 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]
