Hello,
When I have a mapping like (class Forfait):


then it's easy to add / remove elements in the set:
forfait.getServices().add(service)
forfait.getServices().remove(service)

Now if I have to put some information on the association,
then I use composite-element :



Then what is the smartest way to code when I have to add & remove
elements from the Set?

Thanks
--
Franck

The downside of using composite here is that its not an entity and therefore will not receive interceptor callbacks. Of course, you could easily handle that in forfait.

The other option is, of course, to use an entity here but that would require a composite index. So, which is worse, no callbacks or dealing with an composite index?

Jeff

Well,

I think I don't understand something with many-to-many
'composited' Collection.

Actually I really don't see the interest to map a set by :

<set
role="services"
table="tbl_liens_forfaits_services"
>
<key column="forfait_id"/>
<composite-element class="RelationForfaitService">
<property name="precision" type="string"/>
<many-to-one name="service" column="service_id" class="Service"/>
</composite-element>
</set>

against a one-to-many

<set role="services" table="tbl_liens_forfaits_services">
<key column="service_id"/>
<one-to-many class="RelationForfaitService"/>
</set>

The 2 solutions give the same result :
a Set of RelationForfaitService.class instances

With the one-to-many, I have to do a mapping file for
the RelationForfaitService Class

But is-it the only disadvantage of the second solution?

Thanks

Right. Beside the additional mapping file, the entity solution (2nd) typically will require a composit Id class, but it doesn't have to. What is the primate key of RelationForfaitService? Isn't it a composit key? With the 1st solution, you don't need this.

Jeff