Hello Scott,
You are right, because it extends Hashtable a Criteria cannot contain a null
criterion. However, it *can* contain a criterion instance which in turn
specifies a null value.
So in fact, as you mentionned my code snippet was incorrect. Here's how it
should look:
if (pk != null &&
(!criteria.containsKey(pk.getFullyQualifiedName()) ||
criteria.getValue(pk.getFullyQualifiedName())==null))
{
// Proceed with ID generation
}
I will reformulate the whole thing in another message.
Sincere thanks for your note regarding Hashtable.
-- Mathieu
-----Original Message-----
From: Weaver, Scott [mailto:[EMAIL PROTECTED]]
Sent: February 13, 2002 2:18 PM
To: 'Turbine Developers List'
Subject: RE: ID generation bug(?) in BasePeer's doInsert() and
workaround
It should be impossible for a Criteria to contain a null for a mapped key
since in extends Hashtable and a Hashtables cannot contain null values.
So basically
!criteria.contains(pk.getFullyQualifiedName())
and
criteria.get(pk.getFullyQualifiedName())==null
are one in the same.
Scott
> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, February 13, 2002 12:30 PM
> To: 'Turbine Developers List'
> Subject: RE: ID generation bug(?) in BasePeer's doInsert() and
> workaround
>
>
> 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]>
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
