At 06:43 PM 8/16/99 -0700, you wrote:
> 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?
>
Sound practice should stop you. Identity is fundamental to the notion of a
persistent entity, and if you change the primary key, you are subverting
identity.
I (along with a great many others) would argue that password shouldn't be
part of your PK: unless you are dealing with a legacy database and have no
influence over the DB structure, you should use "meaningless" PKs - that
is, values which have no object semantics or meaning attached to them.
> 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".
>
Steve Demuth
Director of Technology Research
Artemis Alliance, Inc. An Inprise Premier Partner
2750 Lannon Hill Road
Decorah, Iowa 52101
651-227-7172 (Typically Mon-Tue) or 319-382-0593 (Wed-Fri)
===========================================================================
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".
