Gotta love components.
Why would the Toy have the child PK as part of it's pk?
In this case, Toy is a second class EJB and shouldn't be having things like
Manual related to it (from a model perspective). I'd have to disagree that
the component interaction as used for this too rdbms like, looks non-rdbms
like to me and more like a networked database.
Thor HW
----- Original Message -----
From: "Louth, William (Exchange)" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Tuesday, May 02, 2000 12:08 PM
Subject: Re: References to EBs from other EBs & CMP
> Hi Jonathan,
>
> Thanks for the interesting post. The only other options I can see
currently
> is that we always use a OID (generated number) as a primary key for all
> beans (green field project....dream on...) or that we require the primary
> key class to contain the primary key "fields" relating to both entities
but
> this is too database like and not OO, places more work on the developer,
is
> potentially impractical in the case of pk fields from both with the same
> name and requires changes to the ejb descriptor. For example :-
>
> public class ToyPK {
> public String name; // this is the name field from the ChildPK class
> public int index; // this is the additional field introduce by the
toy
> }
>
> If we consider that the toy ships with a set of manuals then we have....
>
> public class ManualBean {
> public Toy toy;
> public String manual;
> }
>
> public class ToyManualPK {
> public String name; // this is not very nice really database like
> public int index; // same again
> public String manual;
> }
>
> with this when we map the reference to toy in the ManualBean we will need
to
> map 2 undisclosed cmp fields over some table columns. The container will
> load the 2 fields index and name into the stub for the toy reference and
> when accessed the stub can use these fields and call
> findByPrimaryKey....pause....while typing this email I say another way
maybe
> we can just require that the ToyManual must contain the manual field and a
> ToyPK field and that the ToyPK must contain a name field and ChildPK
> field....
>
> public class ToyManualPK {
> public ToyPK toy;
> public String manual;
> }
>
> There is probably many reasons this solution is just not up to it. Sorry a
> bit unstructured its hard to work and still read this newsgroup....here
> comes another context switch...bye...
>
> William Louth
>
> > -----Original Message-----
> > From: Jonathan K. Weedon [SMTP:[EMAIL PROTECTED]]
> > Sent: Tuesday, May 02, 2000 7:18 PM
> > To: [EMAIL PROTECTED]
> > Subject: Re: References to EBs from other EBs & CMP
> >
> > Jim,
> >
> > I thought I might follow up on your question to:
> >
> > 1) show an example of using references, and
> >
> > 2) set the stage for a question regarding the EJB spec. that has been
> > nagging me for a while.
> >
> > In your example, you have a Child entity which has a reference to an
> > Address entity, and which has references to a collection of Toy
> > entities. Using the normal EJB naming conventions, where Foo is the
> > remote interface and FooBean is the bean implementation class, then
> > you would have the following:
> >
> > public class ChildBean implement EntityBean {
> >
> > public String name; // child's primary key field
> > public Address address; // container managed reference to
> > Address
> > public Collection toys; // container managed collection of
Toys
> >
> > // other stuff omitted
> >
> > }
> >
> > public class Address implements EntityBean {
> >
> > public Integer id; // Address's primary key field
> > public String street; // various container managed fields
> > public String city;
> > public int zipCode;
> >
> > // other stuff omitted
> >
> > }
> >
> > public class Toy implements EntityBean {
> >
> > public Child child; // partial primary key, also a foreign
> > key
> > public int index; // other half of the primary key
> > public String color; // some other container managed fields
> >
> > // other stuff omitted
> >
> > }
> >
> > As you can see, we have container managed fields which are references
> > to the various entities' remote interfaces, or collections thereof.
> > These typically correspond to foreign keys in the underlying schema.
> >
> > <vendor> We too will automatically create the various tables for you,
> > if you are not mapping to preexisting tables.</vendor>
> >
> > The question that has been bothering me has to do with the primary key
> > for Toy. As you can see, Toy's primary key is a composite of a
> > foreign key referring to a Child, and an index indicating which toy it
> > is.
> >
> > (Note that I am assuming the Child-to-Toy relationship is one-to-many,
> > not many-to-many. I.e., two children cannot own the same toy. This
> > is just a simplifying assumption, not a requirement of the model.)
> >
> > Thus, the primary key type of Toy would be:
> >
> > public class ToyPK implements Serializable {
> >
> > public Child child;
> > public int index;
> >
> > public int hashCode() {
> > // details omitted
> > }
> >
> > public boolean equals(Object object) {
> > // details omitted
> > }
> >
> > }
> >
> > So, my question is how can we implement the hashCode and equals
> > method? In the EJB spec., it is required that I implement these
> > methods, but for fields which are remote references, it is not clear
> > to me that there is a portable and performant way to write these
> > methods.
> >
> > The equals method is not overly complicated to implement:
> >
> > public boolean equals(Object object) {
> > if(!(object instanceof ToyPK)) {
> > return false;
> > }
> > ToyPK that = (ToyPK) object;
> > try {
> > return this.index == that.index &&
> > this.child.isIdentical(that.child);
> > }
> > catch(RemoteException e) {
> > // if we are unable to call isIdentical, then assume the
> > references
> > // are not the same
> > return false;
> > }
> > }
> >
> > This was not too hard to write, but unfortunately has poor
> > performance, in that if I am not colocated with the EJBs, I have to do
> > an RPC to the server to handle the isIdentical method.
> >
> > Much harder is writing the hashCode method. Obviously, computing a
> > hash code for an int is trivial, but what about the Child reference.
> > The best that I can do in a totally portable manner is to get the
> > child's handle, serialize it to an object output stream, an then
> > compute a hash code from the stream's underlying byte array:
> >
> > ByteArrayOutputStream byteOutput = new
> > ByteArrayOutputStream();
> > ObjectOutputStream objectOutput = new
> > ObjectOutputStream(byteOutput);
> > Handle handle = child.getHandle();
> > objectOutput.writeObject(handle);
> > byte[] bytes = byteOutput.toByteArray();
> > int hashCode = 0;
> > for(int i = 0; i < bytes.length; i++) {
> > // be careful to rotate the hashCode around, so you get a
> > full
> > // 32 bits of hashing, not just 8 bits.
> > hashCode =
> > (hashCode << 8) & 0xffffff00 |
> > (hashCode >> 24) & 0x000000ff;
> > hashCode += bytes[i];
> > }
> >
> > Obviously, this code is not for the feint of heart, and it is not yet
> > even complete (it does not handle exceptions).
> >
> > Furthermore, I am not totally sure this code will work portably, in
> > that I don't know that an EJBObject reference's handle is guaranteed
> > to serialize to same bytes every time. In fact, I would guess for a
> > lot of servers, it might not.
> >
> > In summary, I think it is pretty much infeasible to implement the
hashCode
> > method for this primary key class. Which leads me to one of the
following
> > conclusions:
> >
> > 1) The EJB spec. should remove the requirement that a primary key class
> > implement
> > hashCode and equals. (I personally see no good reason to need these
> > methods, as
> > it encourages a very non-OO way of interacting with entity beans, but
that
> > is another
> > discussion).
> >
> > 2) The EJB spec. should add a requirement that every EJBObject
> > implement hashCode and equals method. Then, I could easily implement
> > the PK methods as:
> >
> > public int hashCode() {
> > return index + child.hashCode();
> > }
> >
> > public boolean equals(Object object) {
> > if(!(object instanceof ToyPK)) {
> > return false;
> > }
> > ToyPK that = (ToyPK) object;
> > return this.index == that.index &&
> > this.child.equals(that.child);
> > }
> >
> > I apologize if the EJB 2.0 spec has already addressed this, and I just
> > missed it.
> >
> > -jkw
> >
> > Jim Archer wrote:
> > >
> > > Hi All...
> > >
> > > I'm trying to understand how references to entity beans work in EJB
1.1
> > > servers when using CMP. I'm sorry this is kind of convoluted, but I
have
> > > been through a few books and and web sites and have not figured out
how
> > > this works.
> > >
> > > I'm interested in modeling my world using entity beans that have
> > reference
> > > to other entity beans, like I would in any other OO system. I don't
> > > understand how all this works in EJB when I am using CMP.
> > >
> > > If I have an eb that represents a child, and another eb that
represents
> > an
> > > address, I would like to put a reference to an Address eb in my Child
eb
> > > and have CMP handle persisting both of the beans. If I do that will
the
> > > address in some way be persisted with the Child eb (maybe by saving
its
> > > primary key)? When I later do a find that loads the Child eb from the
> > > database will the Address eb be loaded as well?
> > >
> > > Now, what if I want to model the Child having some not fixed number of
> > > toys? I would like for the Child eb to have an instance of a
Collection
> > of
> > > Toy entity beans. Can I do this such that when the Child is persisted
> > that
> > > all the toys get persisted as well?
> > >
> > > Thanks very much!
> > >
> > > Jim
> > >
> > >
> >
==========================================================================
> > =
> > > 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".
>
>
> ***********************************************************************
> Bear Stearns is not responsible for any recommendation, solicitation,
> offer or agreement or any information about any transaction, customer
> account or account activity contained in this communication.
> ***********************************************************************
>
>
===========================================================================
> 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".
