collection mapping

Markus · **Posted:** Wed Jun 29, 2005 6:08 am

Hi all!

In my system I have a Project class and a Volunteer class. Any number of Volunteers can participate in a Project while a Project can have any number of Volunteer participants. I'm using a relation table (T_ProjectsVolunteers) to establish the relation between Projects and Volunteers.

My nhibernate configuration for a Project looks like this (shortened for simplicity)

Code:

   <class name="Project" table="T_Projects">
      <id name="ID" access="property" column="ProjectID" type="Guid">
         <generator class="guid.comb" />
      </id>
      <bag name="Volunteers" table="T_ProjectsVolunteers">
         <key column="ProjectID" />
         <many-to-many class="Volunteer" column="VolunteerID" /> 
      </bag>
   </class>

The relation table looks like this:

Code:

CREATE TABLE [dbo].[T_ProjectsVolunteers] (
   [VolunteerID] [uniqueidentifier] NOT NULL ,
   [ProjectID] [uniqueidentifier] NOT NULL ,
   [AllowViewMasterData] [bit] NOT NULL 
)

As you can see, there is an additional flag (AllowViewMasterData) that is set in combination of ProjectID and VolunteerID. Now my question is how can I access this flag with nhibernate (how can I model it my code and config file)? Do I have to write an own association class?

Thanks

Markus

KPixel · **Posted:** Wed Jun 29, 2005 10:21 am

IMO, once you have more than the two identifiers of <many-to-many> in this middle table, you have to create two <one-to-many> (for each end).

Hibernator · **Joined:** Sat Dec 10, 2005 12:23 am **Posts:** 5

KPixel, can you please elaborate on your response? Thanks!

radu · **Joined:** Wed Jun 15, 2005 4:17 am **Posts:** 156

KPixel is suggesting to transform the many-to-many relationship in two one-to-many, which means that the join table will be mapped to an entity in the domain model (a ProjectVolunteers object). To this new entity you can add as many properties as you want and use them in queries as well.

HTH,
Radu

Nels_P_Olsen · **Posted:** Sat Dec 17, 2005 2:53 pm

We ended up going with this approach (exposing the join table as its own entity) across the board because our product is provided to other developers who can then customize it. Inevitably someone will want to associate properties with the join itself (role descriptions, a "primary member" indicator, etc).

Then when the time comes where someone wants to add properties to the "join" entity itself, there is no need to change the API for how the entities are related, so exisiting queries and code don't break.

Hibernator · **Joined:** Sat Dec 10, 2005 12:23 am **Posts:** 5

Got it. Thx