----- Original Message -----
From: Rickard Öberg <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Friday, August 13, 1999 10:00 PM
Subject: Re: CMP, ContainerManagedFields, and Primary Key
Hey

Murali Krishna Devarakonda wrote:
> Murali Krishna Devarakonda wrote:
> >     The User bean's UserPK primary key class contains:
> >         String     login
> >         String     password
>
> Does this mean that in your system it is not allowed to change password?
> Because this is the consequence of the above.
>
> <MKD>
> What's stopping me from having a "changePassword( String password )"
method?
> </MKD>

There's no way to change the primary key of an object in EJB. It's just
the way it is.

Rickard,
   That's a good point.

    Now the questions in my mind are:
    1. This cannot apply to BMP. Who's stopping me from changing the
"password" field, and writing out the modified field(along with all the
other fields) in ejbStore?

    2. Even in CMP, is it explicitly forbidden in the spec? I don't remember
it that way...
        Implicitly, you may expect that  behavior, but isn't it totally
dependent on the container implementation. I mean, Vendor A might say, the
User exists, hence the primary key fields should never be written to the
database. But Vendor B might just write out all the containerManagedFields,
including "login" and "password" to the database. I could even change the
"login" in that case!
        Isn't it possible? Now, even if the containers implement it in a
standard way- i.e., enforce the principle that the primary key fields cannot
be modified, how do they do it?
        A) Prevent any attempt to change "login" or "password" members  in
the UserBean?
        B) Or let me do A, and never write out the modified "login" and
"password" in "ejbStore".
        B1) If "B", then this could introduce a BUG in the entity beans in
WebLogic server using their "isModified" extension. Unless, the container
throws an exception in "ejbStore" saying something like:
    "primary key field 'password' modified illegally", or something like
that. But that seems backwards. So, I guess, a container will have to
prevent me from modifying the "password" member of my UserBean. But at least
the WebLogic server doesn't.

  3. Even if 2 is implemented correctly, what about 1? I could still
modify the "password" in BMP. And then there's a conflict in the behavior of
the same bean, depending on whether I choose BMP or CMP.

I'd really appreciate a clarification on this topic, as I'm not sure the
spec enforces or even suggests any behavior wrt the Primary key fields.

Also, how should I interpret a PK with 2 or more fields?
a) If it is: "A combination of two or more fields should correspond to a
single item", then what I'm doing should be allowed.
b) If it is: a), AND "The PK members should never be modified", then I think
the spec is not clear on this. Because, while I may be hacking here, my
perspective is that the "user_id" field which is the primary key in the
database, is the only field that must-not/cannot be modified.

My reading of the spec allows me to modify the PK members(which correspond
to the Entity bean's Primary key and are totally different from the database
primary key).

Please correct me if I'm wrong here!

Thanks,
Murali

===========================================================================
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