What Jay means, can be better illustrated with a simple example:
public void method1() {
Bean obj = BeanHome.create("0001");
obj.setAmount(100);
// ^^^^-----------primary key
}
public void method2() {
Bean obj = BeanHome.find("0001");
obj.setID("0002");
}
public int method3 () {
Bean obj = BeanHome.find("0002");
return obj.getAmount();
}
If called in succession, method3 would return (int) 100.
The primary key is semantically inmutable (In practice, it's not enforced by
any server). Any server providing this functionality is also backed by a
RDBMS that allows this. In many legacy DB's, this would result in an error
due to constraints.
Bottom line is, this *may* work in some server/db combinations, but don't
count on it.
In the same line we could talk about changing the persistence info
midstream; example:
Original class (UserBean)
fields:
ID
Name
Later at a reunion: oops, I forgot to add the balance field to the User
EJB!!!
Modified class (UserBean)
fields:
ID
Name
Balance
Re-deploying in most server/db combinations will dump the entire table; but
most enterprise db's support ALTER TABLE commands; what should be standard
behavior?
I think in both cases, these should be treated as server dependant.
My 2c,
JP
> -----Original Message-----
> From: José González Gómez [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, April 04, 2001 4:30 AM
> To: [EMAIL PROTECTED]
> Subject: Re: EJB 1.1 and change of primary key values
>
>
> Jay,
>
> Correct me if I'm wrong, but I think you are supposing you
> have some
> fields in your entity bean that act as primary key, is this right?
>
> regards
> Jose
>
> Jay Walters wrote:
>
> > To keep ejb-interest from becoming a ghost town I'll ask a
> question with I
> > am hoping an obvious answer.
> >
> > In looking at the EJB 1.1 spec I don't see anything that
> keeps me, a bean
> > writer from changing the primary key fields within my
> entity bean (BMP or
> > CMP); there is at least one container that would propagate
> these changes to
> > a CMP entity bean into the database.
> >
> > My question is, since the primary key associated with the
> bean doesn't
> > change; and in general we shouldn't be changing the
> identity of a bean in
> > midstream, shouldn't the container or the CMP persistence
> manager complain
> > about this? Or at the least shouldn't there be something
> in the spec about
> > not doing this when writing an entity bean? Otherwise
> locating the bean by
> > primary key will be sort of a hit or miss thing depending
> on whether it's
> > been re-loaded since the primary key in the bean is updated.
> >
> > Cheers
> > Jay Walters
> >
> >
> ==============================================================
> =============
> > 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".
>
>
> ______________________________________________________________
> ______________
> For your protection, this e-mail message has been scanned for Viruses.
> Visit us at http://www.neoris.com/
>
===========================================================================
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".