> unfortunately, I have asked a simple question for which I am getting all
> sorts of complex answers. Maybe I hve not stated clearly what I need. Let me
> try again:
its a complex question, hence complex answers.
> Lets say we have two CMP beans: a Address bean and a Person Bean.
>
> 1. Can (NOT should, I am not asking a design question) the Person bean have
> Address as a CMP field. I am not asking this with reference to EJB 2.0 Spec,
> I know there is the funda of cmr fields there.
when you have code like:
Address address = addressHome.findByPrimaryKey(new AddressPK(1));
what you get is a reference tot he address. if you were to store that as a persistent
field (by serializing it) then, depending on
how the container worked, it may or may not work. You might be able to store the
handle, but a better approach would be to store
the primary key, and lazy load the instance when you need access to it. THis is the
common way to do realationships in cmp1.1.
So... have something like:
// address is the remote interface to the address entity. this method
// is in the customer entity.
public void setAddress(Address address)
{
setAddressId(address.getId());
// the address field is transient, and does not get stored.
this.address = address;
}
public Address getAddress()
{
if (address == null)
{
address = addressHome.findByPrimaryKey(getAddressId());
}
return address;
}
that obviously doesn't do exception handling, but hopefully you get the idea.
> 2. If one is "Yes", how to create a table for such a Entity bean (I mean
> what will be datatypes of the Person Table in the database, like say,
> Oracle. I specifically mean to ask the datatype of the column that will map
> to the Address field).
as above... you want to have the datatypes as you would for the foreign key as you
would without ejb. in the above instance,
suppose that address.getId() returns a Long type, then you'd have the corresponding
SQL type in the database.
> 3. In EJB 2.0, is this allowed - NOT as a cmr field, but still as a cmp
> field. I do not mean to ask the advantages or dis advantages of such an
> approach.
I'm guessing you could get away with serializing the component interface of an entity
bean in the database, but it wouldn't "work"
(tm) how you want it to.
> Please do not take this as a harsh mail, i needed to be clear on what I am
> asking.
likewise...
bear in mind, this is a complex issue... making objects store themselves is not easy
(o:
a good ejb book goes a long way.
cheers
dim
===========================================================================
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".
