The whole database has idMethod="idbroker". There seem to be three factors required in order for ID generation to occur:
1. table's idMethod is "idbroker" 2. table has a primary key 3. this primary key is not specified in the Criteria What I'm suggesting is to consider using those factors instead: 1. table's idMethod is "idbroker" 2. table has a primary key 3. this primary key is not specified in the Criteria OR it IS specified in the Criteria, but has "null" as value -----Original Message----- From: Weaver, Scott [mailto:[EMAIL PROTECTED]] Sent: February 13, 2002 12:34 PM To: 'Turbine Developers List' Subject: RE: ID generation bug(?) in BasePeer's doInsert() and workaround What value have you set for "idMethod" in your schema? If you want Torque to generate the key, it should be set to idMethod="idbroker". Or (I'm almost positive, someone correct me if I'm wrong) idMethod="native" if you want your RDBMS to generate the key instead. It defaults to idMethod="null" per the DTD spec if you don't specify anything. hth, Scott > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]] > Sent: Wednesday, February 13, 2002 12:15 PM > To: [EMAIL PROTECTED] > Subject: ID generation bug(?) in BasePeer's doInsert() and workaround > > > Greetings to all of you, amazing Turbine developers! :0) > > IDBroker was not working for me, and as I stepped into > BasePeer's doInsert() > method I understood why. I patched BasePeer and now it > works, but I'm still > unsure whether it's a bug or a misunderstanding on my side. > > I apologize in advance if this message should have gone to > the Turbine Users > list instead, but I think Torque's internals are more > appropriate to the > Turbine Dev list (?). > > Here's how it goes: > > I create a new OM object and want to insert it into the > corresponding table > while having Torque automatically generated the primary key > (a NumberKey). > However, the peer's doInsert() calls buildCriteria() which creates a > criterion for ALL columns, including the primary key. Then > when BasePeer's > doInsert() is called with the Criteria, it needs to determine > whether to use > ID generation, and for this purpose checks whether the PK is > specified in > the criteria, which is the case. So it skips ID generation, > and NULL gets > inserted. > > I didn't want to alter buildCriteria() because it's being > used by many other > methods which may require the PK to be specified as criteria, > so my only > option was to modify BasePeer. Instead of only checking for > presence of PK > in Criteria, I also check the value for nullity. This way, a > new object > with a null primary key will have its PK generated correctly. > > Here's the original lines (BasePeer.java, line 775, rev. 1.22 from > jakarta-turbine-torque CVS): > > // pk will be null if there is no primary key defined > for the table > // we're inserting into. > if (pk != null && > !criteria.containsKey(pk.getFullyQualifiedName())) > { > // Proceed with ID generation... > } > > And here's my modified version: > > // pk will be null if there is no primary key defined > for the table > // we're inserting into OR if primary key is null. > if (pk != null && > (!criteria.contains(pk.getFullyQualifiedName()) || > criteria.get(pk.getFullyQualifiedName())==null)) > { > // Proceed with ID generation... > } > > Please let me know if I'm doing things all wrong! ;-) > > Cheers, and keep up the good work folks! > > Best regards, > Mathieu Frenette > Software Architect > Freeborders Canada Inc. > > > -- > 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]>
