-->
These old forums are deprecated now and set to read-only. We are waiting for you on our new forums!
More modern, Discourse-based and with GitHub/Google/Twitter authentication built-in.

All times are UTC - 5 hours [ DST ]



Forum locked This topic is locked, you cannot edit posts or make further replies.  [ 4 posts ] 
Author Message
 Post subject: [xDoclet] Primary key constraint generation
PostPosted: Tue Jan 04, 2005 9:30 am 
Newbie

Joined: Tue Dec 07, 2004 12:44 pm
Posts: 13
Hi! I'm confused about how primary key constraints are generated by xDoclet. I have 2 bidirectional many-to-many relationships which apparently are equivalent (different classes, though), but the primary key constraints generated on the DB are different.

First case: BasicContentData - BasicContent

BasicContentData mapping:

Code:
   /**
    * @hibernate.list name="associatedDocs"
    * lazy="true"
    * table="cm_associated_docs_contents"
    *
    * @hibernate.collection-key
    * column="id_basic_content_data"
    *
    * @hibernate.collection-index
    * column="position"
    *
    * @hibernate.collection-many-to-many
    * class="com.xeridia.cm.content.persistence.BasicContent"
    * column="id_basic_content"
    *
    * @struts.form-field form-name="BasicContentDataForm"
    */
   public List getAssociatedDocs() {
      return associatedDocs;
   }


BasicContent mapping:

Code:
   /**
    * @hibernate.set name="associatedDocsInverse"
    * lazy="true"
    * table="cm_associated_docs_contents"
    * inverse="true"
    *
    * @hibernate.collection-key
    * column="id_basic_content"
    *
    * @hibernate.collection-many-to-many
    * class="com.xeridia.cm.content.persistence.BasicContentData"
    * column="id_basic_content_data"
    *
    * @struts.form-field form-name="BasicContentForm"
    */
   public Set getAssociatedDocsInverse() {
      return associatedDocsInverse;
   }


Generated table:

Code:
CREATE TABLE cm_associated_docs_contents
(
  id_basic_content int8 NOT NULL,
  id_basic_content_data int8 NOT NULL,
  "position" int4 NOT NULL,
  CONSTRAINT cm_associated_docs_contents_pkey PRIMARY KEY (id_basic_content_data, "position"),
  CONSTRAINT fk4d92935a4db5dc5 FOREIGN KEY (id_basic_content_data) REFERENCES cm_basic_content_data (id) ON UPDATE NO ACTION ON DELETE NO ACTION,
  CONSTRAINT fk4d92935ad8e8f544 FOREIGN KEY (id_basic_content) REFERENCES cm_basic_content (id) ON UPDATE NO ACTION ON DELETE NO ACTION
)
WITH OIDS;
ALTER TABLE cm_associated_docs_contents OWNER TO postgresql;


Second case: Layout - Section

Layout mapping:

Code:
   /**
    * @hibernate.list name="sections"
    * lazy="true"
    * table="cm_sections_layouts"
    *
    * @hibernate.collection-key
    * column="id_layout"
    *
    * @hibernate.collection-index
    * column="position"
    *
    * @hibernate.collection-many-to-many
    * class="com.xeridia.cm.manager.persistence.Section"
    * column="id_section"
    *
    * @struts.form-field form-name="LayoutForm"
    */
   public List getSections() {
      return sections;
   }


Section mapping:

Code:
   /**
    * @hibernate.set name="layouts"
    * lazy="true"
    * table="cm_sections_layouts"
    * inverse="true"
    *
    * @hibernate.collection-key
    * column="id_section"
    *
    * @hibernate.collection-many-to-many
    * class="com.xeridia.cm.manager.persistence.Layout"
    * column="id_layout"
    *
    * @struts.form-field form-name="SectionForm"
    */
   public Set getLayouts() {
      return layouts;
   }


Generated table:

Code:
CREATE TABLE cm_sections_layouts
(
  id_layout int8 NOT NULL,
  id_section int8 NOT NULL,
  "position" int4 NOT NULL,
  CONSTRAINT cm_sections_layouts_pkey PRIMARY KEY (id_section, id_layout),
  CONSTRAINT fk31acd8ad1ed9e7c1 FOREIGN KEY (id_section) REFERENCES cm_section (id) ON UPDATE NO ACTION ON DELETE NO ACTION,
  CONSTRAINT fk31acd8adc35206ce FOREIGN KEY (id_layout) REFERENCES cm_layout (id) ON UPDATE NO ACTION ON DELETE NO ACTION
)
WITH OIDS;
ALTER TABLE cm_sections_layouts OWNER TO postgresql;


As you can see, the primary keys are generated in a different way.

CONSTRAINT cm_associated_docs_contents_pkey PRIMARY KEY (id_basic_content_data, "position")

CONSTRAINT cm_sections_layouts_pkey PRIMARY KEY (id_section, id_layout)


In the first case, it's taking one of the foreign keys and the index column. In the second case, it's picking both primary keys. I think both mappings are declared identically. What's the criterion used by xDoclet to generate primary keys? I'm asking this because in the second case (both foreign keys as primary key), PostgreSQL is complaining about primary key constraint violation when I reorder the sections of a layout and perform an update.

Thanks in advance


Top
 Profile  
 
 Post subject: Nevermind
PostPosted: Tue Jan 04, 2005 9:37 am 
Newbie

Joined: Tue Dec 07, 2004 12:44 pm
Posts: 13
Sorry, this post was a completely mistake.


Top
 Profile  
 
 Post subject:
PostPosted: Tue Jan 04, 2005 12:17 pm 
Newbie

Joined: Tue Dec 07, 2004 12:44 pm
Posts: 13
My question was about hbm2ddl, not xDoclet.


Top
 Profile  
 
 Post subject:
PostPosted: Tue Jan 04, 2005 12:48 pm 
Newbie

Joined: Tue Dec 07, 2004 12:44 pm
Posts: 13
OK, I know what was happening. In the inverse mappings I was using Sets instead of Lists, because I don't need the data ordered in those. In the first case, hbm2ddl was processing the mapping with the List first, and in the second one, the mapping with the Set, so it was generating different primary keys (hbm2ddl uses the index column as part of the primary key if it's a List, but if it's a Set, doesn't - quite obvious). If I use Lists in both directions, the primary keys are generated fine.

Sorry for these posts, at least maybe they can be helpful for someone with the same problem as me in the future.


Top
 Profile  
 
Display posts from previous:  Sort by  
Forum locked This topic is locked, you cannot edit posts or make further replies.  [ 4 posts ] 

All times are UTC - 5 hours [ DST ]


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum

Search for:
© Copyright 2014, Red Hat Inc. All rights reserved. JBoss and Hibernate are registered trademarks and servicemarks of Red Hat, Inc.