db-torque-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Greg Monroe" <Greg.Mon...@DukeCE.com>
Subject RE: IdBroker, Native and MSSQL
Date Tue, 20 Dec 2005 03:12:51 GMT
It might be related to the fact that MS SQL won't let you insert
values into an auto_increment field, unless you do a transaction
and set auto_increment off for the table first and then set it 
back on afterwards.  I think that My SQL has a similar 
restriction that requires the use of it's non-standard 
REPLACE statement.
In general, if you are using native autoincrement keys, you 
need to save the record before referencing the keys.  By using
native autoincrement keys, you have ceded all responsibility for 
keys to SQL.  Unfortunately, because autoincrement is a 
psuedo-standard, each SQL DB handles it slightly different. 
IMHO, Torque does the right thing by simply keeping out of
SQL's way instead of trying to impose a larger standard (like
allowing keys to be set).
FWIW, You can check if you need to save the record by isNew() 
methods (or something similar to that).
That said, there probably is a bug in the since that something
like an IllegalStateException or InvalidArgumentException should
be thrown with a meaningful message rather than a null pointer


From: Trey Long [mailto:james_long@provima.com]
Sent: Mon 12/19/2005 5:17 PM
To: Apache Torque Users List
Subject: IdBroker, Native and MSSQL

Alright Torque Experts.

Using MSSQL and trying to save new rows with defaultIdMethod="native".
Now I am getting a null pointer exception In the setPrimaryKey method of
one of the base objects (see excerpt 'stack'). I debugged a little bit
and found that the variable keyGen was always coming back null. The if
statements only deal with keyGen not being null, in fact, I don't see
how keyGen could ever be set to null after the outermost if(keyGen !=
null...). Take a look at the excerpt from BasePeer.class to see what I
am talking about.

At least there is a little section that seems like it would never be
thrown thus giving me the NullPointerException. At most there is some
flaw in the handling of auto-increment PK's in SQL server.

Is there a known issue with autoincrement PK's in MSSQL server? Does
something come to mind that I am doing wrong?

Excerpt from Stack:
>     [junit] java.lang.NullPointerException
>     [junit]     at
> com.provima.pcsw.db.gen.base.BaseUnderwritingApp.setPrimaryKey(BaseUnderwritingApp.java:1012)
>     [junit]     at
> com.provima.pcsw.db.gen.base.BaseUnderwritingAppPeer.doInsert(BaseUnderwritingAppPeer.java:608)
>     [junit]     at
> com.provima.pcsw.db.gen.base.BaseUnderwritingApp.save(BaseUnderwritingApp.java:982)
>     [junit]     at
> com.provima.pcsw.db.gen.base.BaseUnderwritingApp.save(BaseUnderwritingApp.java:946)
>     [junit]     at
> com.provima.pcsw.db.gen.base.BaseUnderwritingApp.save(BaseUnderwritingApp.java:926)
>     [junit]     at
> com.provima.pcsw.db.test.TestDatabase.testSave(TestDatabase.java:51)
Excerpt from BasePeer.class:
>         IdGenerator keyGen = tableMap.getIdGenerator();
>         ColumnMap pk = getPrimaryKey(criteria);
>         // If the keyMethod is SEQUENCE or IDBROKERTABLE, get the id
>         // before the insert.
>         if (keyGen != null && keyGen.isPriorToInsert())
>         {
>             // 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()))
>             {
>                 if (keyGen == null)
>                 {
>                     throw new TorqueException(
>                             "IdGenerator for table '" + table + "' is
> null");
>                 }
>                 id = getId(pk, keyGen, con, keyInfo);
>                 criteria.add(pk.getFullyQualifiedName(), id);
>             }
>         }

To unsubscribe, e-mail: torque-user-unsubscribe@db.apache.org
For additional commands, e-mail: torque-user-help@db.apache.org

Duke CE Privacy Statement
Please be advised that this e-mail and any files transmitted with it are confidential communication
or may otherwise be privileged or confidential and are intended solely for the individual
or entity to whom they are addressed.  If you are not the intended recipient you may not rely
on the contents of this email or any attachments, and we ask that you  please not read, copy
or retransmit this communication, but reply to the sender and destroy the email, its contents,
and all copies thereof immediately.  Any unauthorized dissemination, distribution or copying
of this communication is strictly prohibited.

View raw message