In the scenario you describe below where and when do you create your
correlation entity bean instances?
Assuming these are not just read only entity beans can you describe the API
in Person and Door that allows you to create associations b/w them.
Presumably you have some kind of
Person.addDoor
Do these maintain collections ie. call getAccessibleDoors() and
then add the passed in door to the list so you have an updated collection of
your accessible doors whenever you make a change? Or does the client have
call getAccessibleDoors and have these lazily
fetched each time?
Door.addPerson
API?
Does your containers CMP handle the instantiation of your PersonDoorAccess
objects for you? If now how is that handled?
In ejb2 you'd have declared abstract methods like
setDoors
setPersons
but that's only possible if you don't have attributes to set. So I'd like to
know exactly how you manage your correlation entity when you do this 1.1
style.
> -----Original Message-----
> From: A mailing list for Enterprise JavaBeans development
> [mailto:[EMAIL PROTECTED]]On Behalf Of Robert Krueger
> Sent: Tuesday, February 20, 2001 2:30 AM
> To: [EMAIL PROTECTED]
> Subject: Re: Modeling relationships with attributes with EJB2.0 CMP
>
>
> Hi Krish,
>
> well I have the impression that all those are workarounds for something
> that could be solved rather easily by the spec authors. Fact is, that
> relationship attributes are commonplace in
> many-many-relationships and that
> everyone implements them some way. Viewing the relationship as an object
> (as in the case of modelling the relationship as an entity) IMHO is a
> rather object-oriented approach, yet it's rather heavyweight. IMHO all
> that's missing is the definition of a semantically clean way of accessing
> relationship attributes. The way we implement it today on top of EJB1.1 is
> as follows:
>
> we have three entities (suppose the many-many relationship is
> bidirectional)
>
> Person
> Door
> PersonDoorAccess
>
> in the remote interface of Person we have methods:
>
> Collection getAccessibleDoors(); (implemented lazily using
> finders on top
> of the CMP engine)
> PersonDoorAccess getPersonDoorAccess(Door); (also implemented
> with finders,
> throwing ObjectNotFound if there is no relationship between the two)
>
> in analogy in Door we have
>
> Collection getPersonsWithAccess();
> PersonDoorAccess getPersonDoorAccess(Person);
>
> in PersonDoorAccess we have stuff like get/setPIN() or
> get/setLastAccessed()
>
> This works very well for us in practice as navigating the relationship is
> efficient because no intermediate steps are taken and editing the
> relationship attributes is easy but I would whish for something similar to
> be part of the CMP contract for relationships. Let's wait and see what the
> next iteration of the spec will bring.
>
> regards,
>
> robert
>
>
> At 10:42 20.02.2001 , you wrote:
> >Hi Robert,
> >
> >I think there could be another approach to what you
> >described, and this is what we (at our organization)
> >use. (ejb spec 1.1 though ... i am looking at the 2.0
> >but at the moment i don't see any solution there)
>
> <snip/>
> (-) Robert Krüger
> (-) SIGNAL 7 Gesellschaft für Informationstechnologie mbH
> (-) Brüder-Knauß-Str. 79 - 64285 Darmstadt,
> (-) Tel: 06151 665401, Fax: 06151 665373
> (-) [EMAIL PROTECTED], www.signal7.de
>
> ==================================================================
> =========
> 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".
>
===========================================================================
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".
