Re: Decomposed m:n mapping with ojb and jdo
Christoph Hermann schrieb: Hello again, The problem seems to lie here: !-- ProfileMenuCategory -- class-descriptor class=papillon.ProfileMenuCategory table=rel_profiles_menu_categories field-descriptor name=profile_id column=profiles_id jdbc-type=INTEGER primarykey=true / field-descriptor name=category_id column=menu_categories_id jdbc-type=INTEGER primarykey=true / field-descriptor name=sortNr column=sort_nr jdbc-type=INTEGER / reference-descriptor name=profile class-ref=papillon.Profile auto-retrieve=true auto-update=false auto-delete=false foreignkey field-ref=profile_id / /reference-descriptor reference-descriptor name=category class-ref=papillon.MenuCategory auto-retrieve=true auto-update=false auto-delete=false foreignkey field-ref=category_id / /reference-descriptor /class-descriptor I can insert Profiles and categories, but i can't insert ProfileMenucategories. Can someone enlight me what is wrong with this definition? Christoph pgpTmHVcYTZfc.pgp Description: PGP signature
Re: Decomposed m:n mapping with ojb and jdo
Both your references use a primarykey part as their foreignkey. Is this really what you want ? The referenced objects must then have the same primarykey value (part) as the ProfileMenuCategory object, and that before you store the ProfileMenutCategory object, otherwise you would overwrite your primarykey, which you definitly don't want. IMO it is easier to have separate fields in ProfileMenuCategory that are only used as foreignkey holders. And for references you can even use anonymous fields, i.e. you don't need real java fields, you can simply add two field descriptors with access=anonymous. Tom - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Decomposed m:n mapping with ojb and jdo
Thomas Dudziak schrieb: Hello, Both your references use a primarykey part as their foreignkey. Is this really what you want ? The referenced objects must then have the same primarykey value (part) as the ProfileMenuCategory object, and that before you store the ProfileMenutCategory object, otherwise you would overwrite your primarykey, which you definitly don't want. IMO it is easier to have separate fields in ProfileMenuCategory that are only used as foreignkey holders. And for references you can even use anonymous fields, i.e. you don't need real java fields, you can simply add two field descriptors with access=anonymous. Thanks for your answer. I think you hit the point, but i don't exactly know how i would correct it. The code (snippet) is used to figure out where the problem was, is: var pc = new Packages.papillon.ProfileMenuCategory(); pc.setCategory_id(13); pc.setProfile_id(15); pc.setSortNr(1); dao.insert(pc); I get the following exception: ERROR: DAO (org.apache.ojb.broker.PersistenceBrokerSQLException: SQL failure while insert object data for class papillon.ProfileMenuCategory, PK of the given object is [ profile_id=20 category_id=16], object was [EMAIL PROTECTED], exception message is [FEHLER: Einfügen oder Aktualisieren in Tabelle »rel_profiles_menu_categories« verletzt Fremdschlüssel-Constraint »$1« ]) I try to explain what i wanted to acomplish: Profile has a primary Key MenuCategory has a primary key ProfileMenuCategory has (in the database) a primary key (to ensure the relationship can only exist once) consisting of both of these with a foreign key constraint. When i do this, pc.setCategory_id(13); pc.setProfile_id(15); i want the fields in the database stored, and the instances of category and profile in profilemenucategory populated by the objects corresponding to these ids. How can i accomplish this? (Can you show me how the repository.xml for ProfileMenuCategory should look like?) Thx for your help so far, Christoph pgpTR8Cod7fG7.pgp Description: PGP signature
Re: Decomposed m:n mapping with ojb and jdo
Thomas Dudziak schrieb: Hello, You should not use the primarykey for this. It would be better if you add a simple primarykey field to the ProfileMenuCategory, make the other two fields normal fields, and in the database add a unqiue constraint on these two fields. This way, the database will throw an exception when a ProfileMenuCategory object is inserted whose combination of these fields has already been used. No, this is against everything i know of database design. The way you desribed it you are creating an additional _not_needed_ primary key. An entry in the relation-table is identified by the two foreign keys which together build the primary key of this table. Christoph pgpAeLk30mAiv.pgp Description: PGP signature
