I understand your warnings against a primary key having any informational content, though this admonition has always made me wonder why we still have composite keys around. In the context of Torque, it again makes me wonder, why do we have ComboKey around?
Actually, I need neither TRANSACTION_ID nor LOG_ID to be unique, though the combination of them should be. This is what led me to consider using ComboKey. LOG_ID provides a simple "history" to an element in the table. In practice, the data would look something like this: TRANSACTION_ID LOG_ID VAL1 VAL2 ... 1 1 a b 1 2 a c 1 3 b c 2 1 A B 2 2 X Y 3 1 1 0 etc. I may, as you suggest, add a new column--say RECORD_ID--and make it the simple primary key, thus stripping all information from the primary key as you suggest. One consequence of this is that I will no longer be looking things up by their primary key, but instead by a combination of two attributes. These are my options, and I'm happy implementing either, but I'm wondering what others may've done in similar situations. Thanks, David -----Original Message----- From: Kurt Schrader [mailto:[EMAIL PROTECTED]] Sent: Thursday, April 18, 2002 2:45 PM To: Turbine Torque Users List Subject: Re: How to use ComboKey? 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]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
