On Thu, 18 Apr 2002 [EMAIL PROTECTED] wrote:
> I have a table called TRANSACTION, with TRANSACTION_ID and LOG_ID fields.
> I'd like these to be part of a composite primary key. How do I do this?
> I've set primaryKey="true" for both fields in the schema file, but what
> next? Primarily, I'm interested in this problem:
>
> When I "edit" a Transaction, what I really want to do is fetch the row for
> the given TRANSACTION_ID that has the "largest" LOG_ID, clone that row,
> increment the LOG_ID by 1, set any attributes that the user changed, and
> then persist it back to the database through transaction.save(). How do I
> do this in the face of unique ids automatically fetched from the IdBroker?
>From experience, this is a bad idea. You should only have one primary
key, and it shouldn't have any meaning. TRANSACTION_ID should be a
separate field that's set to be unique and so should LOG_ID. Why do you
need them to be the primary key? Does the LOG_ID even need to be unique?
What if the rules change in the future and you need some other identifying
feature in your tables? Then any logic that is tied to your "comboKey" is
hosed by a bunch of new comboKeys.
It seems to me that you can do this just as easily with two fields, rather
than tying your logic to your primary key.
-Kurt
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
