Many-to-many association fetched multiple times

tmccobb3 · **Joined:** Wed Feb 14, 2007 11:18 am **Posts:** 10

Hibernate v 3.2.6.

Relationships in question are:

PERSON <--- many to many bidirectional with join table ---> Registrations
|
|
one to many
|
|
Donations

The Registrations collection is mapped as bag; donations are a Set. Here are snippets from the mapping docs:

Code:

<hibernate-mapping auto-import="false"
   package="com.ravencsi.hibernate">
   <class name="com.ravencsi.hibernate.Entity" table="person1"
      catalog="acc">
      <id name="personId" type="java.lang.Long">
         <column name="person_id" />
         <generator class="identity"></generator>
      </id>
      <discriminator column="entity_type" type="string" />


      <property name="guid" type="java.lang.String">
         <meta attribute="use-in-equals">true</meta>
         <column name="guid" length="100" unique="true"
            not-null="true" />
      </property>

               <bag name="registrations" table="person_catalog" lazy="true" outer-join="false">
         <key>
            <column name="person_id" />
         </key>
         <many-to-many class="com.ravencsi.hibernate.Catalog" outer-join="false"
            column="catalog_id" unique="false" />
      </bag>   

....

               <set name="donations" inverse="true" >
         <key column="person_id" not-null="true" />
         <one-to-many class="com.ravencsi.hibernate.Donation" />
      </set>
   </class>
</hibernate-mapping>

<hibernate-mapping>
    <class name="com.ravencsi.hibernate.Donation" table="donations" catalog="acc">
        <id name="donationId" type="java.lang.Long">
            <column name="donation_id" />
            <generator class="identity" />
        </id>
        
        <many-to-one name="person" column="person_id" class="com.ravencsi.hibernate.IPerson"/>
            
        <property name="donationType" type="java.lang.String">
            <column name="donation_type" length="45" not-null="true" />
        </property>
.....

    </class>
</hibernate-mapping>

On the registrations side (class is Catalog) the mapping looks like this:

Code:

<hibernate-mapping>
   <class name="com.ravencsi.hibernate.Catalog" table="catalog" catalog="acc">
      <id name="catalogId" type="java.lang.Integer">
         <column name="catalog_id" />
         <generator class="identity"></generator>
      </id>
.....

      <property name="workshopId" type="java.lang.Long">
                     <column name="workshop_id" />
                </property>
      
      
      <bag name="persons" table="person_catalog"  inverse="true"
        cascade="save-update"  >
         <key>
            <column name="catalog_id" />
         </key>
         <many-to-many class="com.ravencsi.hibernate.Person">
            <column name="person_id" />
         </many-to-many>
      </bag>


   </class>
</hibernate-mapping>

I have had the Registrations collection mapped to a Set until just recently when I changed it to a bag specifically to allow duplicates (the underlying table indices were changed accordingly). Now when I call getRegistrations() on a Person object, I get the number of actual registrations TIMES the number of donations. In other words, if a person has 4 registrations and three donations, I get the registrations in the 3 times, or 12 registrations.

There is no issue with calling getRegistrants() on the Catalog class; the appropriate number of people are returned.

I cannot figure this one out, and I have run out of ideas, unless it has something to do with using an index in a list mapping or idbag which I may not be understanding fully.

Tom McCobb

tmccobb3 · **Joined:** Wed Feb 14, 2007 11:18 am **Posts:** 10

I can see what is happening in the SQL, which returns columns for the donation data, hence the three result rows the following SQL will return for each of three donations associated with this persons three donations.

Quote:

select
this_.person_id as person1_3_5_,
this_.guid as guid3_5_,
this_.create_date as create4_3_5_,
this_.modify_date as modify5_3_5_,
this_.relationship as relation6_3_5_,
this_.notetext as notetext3_5_,
this_.phone1 as phone8_3_5_,
this_.phone2 as phone9_3_5_,
this_.website as website3_5_,
this_.active as active3_5_,
this_.acct_bal as acct12_3_5_,
this_.contact_phone as contact13_3_5_,
this_.roles as roles3_5_,
this_.source as source3_5_,
this_.email_only as email16_3_5_,
this_.last_name as last17_3_5_,
this_.first_name as first18_3_5_,
this_.initial as initial3_5_,
this_.suffix as suffix3_5_,
this_.salutation as salutation3_5_,
this_.dob as dob3_5_,
this_.gender as gender3_5_,
this_.ethnicity as ethnicity3_5_,
this_.company_id as company25_3_5_,
this_.instructor as instructor3_5_,
this_.staff as staff3_5_,
this_.artist as artist3_5_,
this_.user_name as user28_3_5_,
this_.pword as pword3_5_,
this_.title as title3_5_,
this_.department as department3_5_,
this_.comproles as comproles3_5_,
this_.email as email3_5_,
this_.artist_study as artist34_3_5_,
this_.artist_work as artist35_3_5_,
this_.artist_influences as artist36_3_5_,
this_.artist_output as artist37_3_5_,
this_.artist_awards as artist38_3_5_,
this_.artist_appointments as artist39_3_5_,
this_.comp_name as comp41_3_5_,
this_.comp_type as comp42_3_5_,
this_.comp_matching as comp43_3_5_,
this_.comp_match_limit as comp44_3_5_,
donations2_.person_id as person2_7_,
donations2_.donation_id as donation1_7_,
donations2_.donation_id as donation1_44_0_,
donations2_.person_id as person2_44_0_,
donations2_.donation_type as donation3_44_0_,
donations2_.donation_date as donation4_44_0_,
donations2_.solicitation_type as solicita5_44_0_,
donations2_.source_id as source6_44_0_,
donations2_.amount as amount44_0_,
donations2_.inkind as inkind44_0_,
donations2_.anonymous as anonymous44_0_,
donations2_.donor_type as donor10_44_0_,
donations2_.balance as balance44_0_,
donations2_.paid as paid44_0_,
donations2_.donation_yr as donation13_44_0_,
donations2_.donation_qtr as donation14_44_0_,
donations2_.tactic_id as tactic15_44_0_,
donations2_.frequency as frequency44_0_,
donations2_.pay_interval as pay17_44_0_,
donations2_.pay_date as pay18_44_0_,
member3_.member_id as member1_14_1_,
member3_.category_id as category2_14_1_,
member3_.create_year as create3_14_1_,
member3_.expire_date as expire4_14_1_,
member3_.card_printed as card5_14_1_,
member3_.cost as cost14_1_,
membership4_.category_id as category1_16_2_,
membership4_.category_descr as category2_16_2_,
membership4_.accountID as accountID16_2_,
membership4_.selection as selection16_2_,
membership4_.household as household16_2_,
membership4_.cost as cost16_2_,
membership4_.discounts as discounts16_2_,
membership4_.inactive as inactive16_2_,
membership4_.contributing as contribu9_16_2_,
membership4_.details as details16_2_,
instructor5_.instructor_id as instructor1_46_3_,
instructor5_.website as website46_3_,
instructor5_.media as media46_3_,
instructor5_.bio as bio46_3_,
instructor5_.education as education46_3_,
instructor5_.distinctions as distinct6_46_3_,
company6_.person_id as person1_3_4_,
company6_.guid as guid3_4_,
company6_.create_date as create4_3_4_,
company6_.modify_date as modify5_3_4_,
company6_.relationship as relation6_3_4_,
company6_.notetext as notetext3_4_,
company6_.phone1 as phone8_3_4_,
company6_.phone2 as phone9_3_4_,
company6_.website as website3_4_,
company6_.active as active3_4_,
company6_.acct_bal as acct12_3_4_,
company6_.contact_phone as contact13_3_4_,
company6_.roles as roles3_4_,
company6_.source as source3_4_,
company6_.email_only as email16_3_4_,
company6_.last_name as last17_3_4_,
company6_.first_name as first18_3_4_,
company6_.initial as initial3_4_,
company6_.suffix as suffix3_4_,
company6_.salutation as salutation3_4_,
company6_.dob as dob3_4_,
company6_.gender as gender3_4_,
company6_.ethnicity as ethnicity3_4_,
company6_.company_id as company25_3_4_,
company6_.instructor as instructor3_4_,
company6_.staff as staff3_4_,
company6_.artist as artist3_4_,
company6_.user_name as user28_3_4_,
company6_.pword as pword3_4_,
company6_.title as title3_4_,
company6_.department as department3_4_,
company6_.comproles as comproles3_4_,
company6_.email as email3_4_,
company6_.artist_study as artist34_3_4_,
company6_.artist_work as artist35_3_4_,
company6_.artist_influences as artist36_3_4_,
company6_.artist_output as artist37_3_4_,
company6_.artist_awards as artist38_3_4_,
company6_.artist_appointments as artist39_3_4_,
company6_.comp_name as comp41_3_4_,
company6_.comp_type as comp42_3_4_,
company6_.comp_matching as comp43_3_4_,
company6_.comp_match_limit as comp44_3_4_
from
acc.person1 this_
inner join
acc.donations donations2_
on this_.person_id=donations2_.person_id
left outer join
acc.member member3_
on this_.person_id=member3_.member_id
left outer join
acc.membership_cat membership4_
on member3_.category_id=membership4_.category_id
left outer join
acc.instructor instructor5_
on this_.person_id=instructor5_.instructor_id
left outer join
acc.person1 company6_
on this_.company_id=company6_.person_id
where
this_.entity_type='NP'
and this_.person_id=52507

tmccobb3 · **Joined:** Wed Feb 14, 2007 11:18 am **Posts:** 10

Found a problem in the DAO which was re-initializing the donation collection unnecessarily with a FetchMode.JOIN setting. That solves my immediate problem.

I think if I understand 7.3.1 of the documentation correctly I should probably be using a join table for this anyway.