Justin, You are correct. I was referring specifically to Torque, which treats primaryKey columns as auto-generated (at least, this is my understanding having perused the code.)
When I have tables where I don't want auto-generated keys, I have generally avoided stating that the column is a "PrimaryKey" - instead, I create a <unique> constraint on the table instead. And then, of course, you have to have some mechanism for setting the column value to a unique key. Nonetheless, you're right that, in the general world of schema design, there is no requirement that a primaryKey be a number or that it be auto-generated. But I'll go out on a limb and say that I believe it's a 'best-practice'! Others may disagree. :) -Peter On Mon, 2003-02-10 at 18:20, Campbell, Justin wrote: > Peter - > > I would argue whether or not primary keys are auto-generated by definition. > This statement is true of "identity" (SQL Server terminology used here; > a.k.a. AutoNumber, ID, etc.) columns. However, a primary key can consist of > one or more non-identity columns (e.g. a varchar(50) value). > > Personally, all my primary keys *are* identity columns (as this makes it > easier to isolate the actual "key" value and eases changes to the key > combination in the future), but this is not necessary (nor even recommended > by some schools of thought in DB schema design). > > Just thought I'd clarify for folks out there as this statement may cause > confusion among the uninitiated. > > Best of luck. > > - Justin > > -----Original Message----- > From: Peter S. Hamlen [mailto:[EMAIL PROTECTED]] > Sent: Monday, February 10, 2003 6:22 PM > To: Turbine Torque Users List > Subject: Re: how to set the PK manually? > > > Marc, > > My understanding is that you cannot accomplish this if it's a primary > key. Primary keys, by their definition, are generated automatically so > that there aren't any duplicates. > > As Justin Campbell mentioned in a previous email, you might want to have > Table B have a foreign-key to table A (that's how most of us accomplish > this.) > > The other option (if you're really talking about "extending") is to add > the columns for B into table A - and add a "type" column that indicates > whether the object in the table is of type A or B. > > For example: > > <table name="PaymentPlans"> > <column name="Type" description="Annual or Monthly"/> > <column name="MonthlyBillDate" description="Only used for Monthly > types"/> > <column name="AnnualBillDate" description="Only used for annual > plans"/> > <column name="AmountDue" type="INTEGER"/> > </table> > > You can find more information about this in the "Inheritance" section of > Torque. > > -Peter > On Thu, 2003-02-06 at 13:20, Marc Lustig wrote: > > Hi, > > > > I'm creating a new instance (row) and set the PK to a certain value. > > (I need to do this because this table B extends another table A, so the PK > > in table B must be the same as in table A.) > > > > My defaultIdMethod is "idbroker": > > <database defaultIdMethod="idbroker"... > > > > And to make torque not generating the PK I set idMethod="none": > > <table name="B" idMethod="none"> > > > > Problem is when I trigger save() torque still generates a new PK and > assigns > > it. How comes that? > > How can I make torque not to auto-generate a new primary key when save() > is > > called? > > > > Thanks! > > > > Marc > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
