[Responses inline.  I tried to trim but I thought I should keep the entirety of
David's explanations for clarity]

> From: A mailing list for Enterprise JavaBeans development
> [mailto:[EMAIL PROTECTED]]On Behalf Of David Levine

> I want to create two entity beans, say one is called Group and one is
> called User.  The group bean contains a name and other attributes.
> The user bean has a bunch of its own attributes, one of which is a
> group.  A User can belong to only one Group, and a Group can have
> hundreds of thousands of Users.
>
> If I were creating a straight Java application using JDBC to access
> the database, and did everything myself (no J2EE) I would have
> created a Group table and a User table.  The User table would have a
> foreign key for whatever Group it belonged to, and the Group would
> NOT have any foreign keys back to the users.  After all, this is a
> One-To-Many (Group-To-User) relationship, and it need only be unidirectional.
>
> Now, with J2EE, I figure I should create two CMP 2.0 beans.  The
> Group bean would have local (rather than remote) interfaces, and the
> User bean would be able to get and set the GroupLocal.  Of course,
> the User's remote interface would not allow access to the Group's
> local interface, but instead would be able to offer a GroupView
> object, or something like that.
>
> (In fact, in the long run, it is unlikely the client will ever
> actually use the Entity Beans, but will use some sort of Session Bean
> as an intermediary).
>
> So far, so good.  But I started getting confused when trying to write
> the deployment descriptor, especially when I got to the ejb-relation section.
>
> Am I correct in doing the following?:
>
> <ejb-relation>
>   <ejb-relation-name>GroupUser</ejb-relation-name>
>   <ejb-relationship-role>
>     <ejb-relationship-role-name>GroupHasUsers</ejb-relationship-role-name>
>     <multiplicity>One</multiplicity>
>     <relationship-role-source>
>       <ejb-name>Group</ejb-name>
>     </relationship-role-source>
>   </ejb-relationship-role>
>   <ejb-relationship-role>
>     <ejb-relationship-role-name>UserInGroup</ejb-relationship-role-name>
>     <multiplicity>Many</multiplicity>
>     <relationship-role-source>
>       <ejb-name>User</ejb-name>
>     </relationship-role-source>
>     <cmr-field>
>       <cmr-field-name>group</cmr-field-name>
>     </cmr-field>
>   </ejb-relationship-role>
> </ejb-relation>
>
> The reason I am confused as to whether or not this is right is that
> all the examples I have seen showing unidirectional one-to-many
> relationships are always showing the object with multiplicity "one"
> being the object with the reference (and it is always a Collection or
> a Set, therefore).  In my case, however, it is the object with
> multiplicity "many" that has the reference (and of course it is
> therefore a single object, rather than a Set or Collection).

This is implementation-dependent, and I can't really see why a container would
implement a unidirectional one-to-many relationship with the one side keeping
all references of the beans they are related to.  It doesn't make sense.

That being said, this issue doesn't have anything to do with the deployment
descriptor:  just because you specify a cmr field on one side of the
relationship doesn't mean it is this side that will maintain the relationship in
the database (the container might resolve this side with internal finders.  Once
again, this is implementation dependent and you shouldn't worry about it).

I can't see anything wrong with the deployment descriptor you posted, what error
are you seeing?

Two side notes:

- You might want to try EJBGen, http://beust.com/cedric/ejbgen
- Our distribution comes with quite a few examples illustrating local
interfaces, relationships, compound primary keys, automatic key generation,
etc...  You might want to check them out

--
Cedric

===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff EJB-INTEREST".  For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".

Reply via email to