db-torque-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Marc Lustig" <m...@marclustig.com>
Subject AW: AW: how to set the PK manually?
Date Thu, 13 Feb 2003 21:56:49 GMT
A few days ago I tried it with idMethod="none", and it didn't work.
Then I switched to idMethod="null" which didn't work either.
Now I tried it again with "none" and it works!
My only explanation is that previously I used setTableId() to set the PK,
not I use setPrimaryKey().

So, solution for the whole issue seems to be:
a) idMethod="none" in the table-element
b) setPrimaryKey() to set the PK (and not setTableId() or setObject() )

Thanks for assisting...


> -----Ursprüngliche Nachricht-----
> Von: Bill [mailto:bhalpin@collaborativefusion.com]
> Gesendet: Donnerstag, 13. Februar 2003 22:15
> An: Turbine Torque Users List
> Betreff: Re: AW: how to set the PK manually?
>
>
> Marc
>
> Just out of curiosity, have you tried setting idMethod to 'none' instead
> of null?  I just remember that being an option and wonder if it would
> make a difference.
>
>
>
>
> On Thu, 2003-02-13 at 15:54, Marc Lustig wrote:
> > Interesting enough I found this in
> > BasePeer.public static ObjectKey doInsert(Criteria criteria,
> Connection con)
> >
> >         // only get a new key value if you need to
> >         // the reason is that a primary key might be defined
> >         // but you are still going to set its value. for example:
> >         // a join table where both keys are primary and you are
> >         // setting both columns with your own values
> >
> > So obviously my scenario is considered a valid one.
> > But I'm not quite sure where the actual decision is made if a new PK is
> > acquired or not.
> > Can some Torque developer please advise me why in my case still
> a new PK is
> > generated, although I set it using setPrimaryKey() before?
> >
> > Marc
> >
> >
> >
> > > -----Ursprüngliche Nachricht-----
> > > Von: Marc Lustig [mailto:mail@marclustig.com]
> > > Gesendet: Dienstag, 11. Februar 2003 15:59
> > > An: Turbine Torque Users List
> > > Betreff: AW: how to set the PK manually?
> > >
> > >
> > > Thanks Justin and Peter for your input,
> > > my statement "TABLE B extends TABLES A" didn't refer to the
> > > OO-terminology.
> > > table A actually respresents a base-user. table B represents a
> > > specific kind
> > > of a user. So both tables refer to the same kind of object, the user.
> > > Hence the PK of table B should reflect the PK that was
> created in table A.
> > >
> > > So my schema (table B) looks like this:
> > >
> > > 	<table name="SPECIALUSER" idMethod="null">
> > > 		<column name="SPECIALUSER_ID" primaryKey="true"
> > > required="true"
> > > type="INTEGER"/>
> > > 		<foreign-key foreignTable="BASE_USER">
> > > 			<reference local="SPECIALUSER_ID"
> > > foreign="USER_ID"/>
> > > 		</foreign-key>
> > >
> > > Problem is still, when I setPrimaryKey(x) this PK will get lost
> > > once I call
> > > save(). torque generates a new PK.
> > >
> > > Q: Is there any other idMethod that I could use to tell torque not to
> > > generate any PK when save() is called?
> > > Or is the only way to add a regular PK and refer the USER-table by an
> > > additional column linked by a foreign-key reference?
> > >
> > > Thanks!
> > > Marc
> > >
> > >
> > >
> > > > -----Ursprüngliche Nachricht-----
> > > > Von: Campbell, Justin [mailto:jcampbell@profilesys.com]
> > > > Gesendet: Dienstag, 11. Februar 2003 00:21
> > > > An: 'Turbine Torque Users List'
> > > > Betreff: RE: how to set the PK manually?
> > > >
> > > >
> > > > 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:phamlen@mail.com]
> > > > 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: torque-user-unsubscribe@db.apache.org
> > > > > For additional commands, e-mail: torque-user-help@db.apache.org
> > > > >
> > > >
> > > >
> > > >
> > > >
> ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: torque-user-unsubscribe@db.apache.org
> > > > For additional commands, e-mail: torque-user-help@db.apache.org
> > > >
> > > >
> ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: torque-user-unsubscribe@db.apache.org
> > > > For additional commands, e-mail: torque-user-help@db.apache.org
> > > >
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: torque-user-unsubscribe@db.apache.org
> > > For additional commands, e-mail: torque-user-help@db.apache.org
> > >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: torque-user-unsubscribe@db.apache.org
> > For additional commands, e-mail: torque-user-help@db.apache.org
> >
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: torque-user-unsubscribe@db.apache.org
> For additional commands, e-mail: torque-user-help@db.apache.org
>


Mime
View raw message