Re: silent failure on insert?

[Joe Germuska]

For what it's worth, I trimmed down my class-descriptor little by 
little, in hopes of finding that an error there was knocking things 
out of wack.  I trimmed it to the point of leaving NOT NULL 
properties out of the class-descriptor, which should have resulted in 
SQL Exceptions, and they never came up, making me think that somehow, 
the insert just wasn't getting executed.

I built OJB from the current CVS Head and the SQL Exceptions started 
to show up, and then when I built my class-descriptor back up, it now 
works.

However, If I switch back to using the db-ojb-1.0.rc5.jar from 
iBiblio, the odd behavior comes back.  Could there be a problem with 
the JAR there?  I've been using it for other stuff, including other 
class-descriptors for this project, but something weird started 
happening when I got to this object mapping.

I'm having some trouble wrangling maven to build RC 5 from CVS, so I 
guess I'll just go ahead using the nightly build.

Joe

At 11:26 AM -0600 2/11/04, Joe Germuska wrote:
Using OJB 1.0rc5, I'm having some strange "silent" failures when I 
try to store an object.  With logging cranked up to DEBUG for all of 
org.apache.ojb , this is all I see:

DEBUG accesslayer.sql.SqlGeneratorDefaultImpl - SQL:INSERT INTO ...
DEBUG broker.accesslayer.JdbcAccessImpl - executeInsert: null
There's only one place in JdbcAccessImpl where that log message 
could come from (because the string 'executeInsert:' only appears 
there):

--------
JdbcAccessImpl : lines 225-239:
            stmt = broker.serviceStatementManager().getInsertStatement(cld);
            if (stmt == null)
            {
                logger.error("getInsertStatement returned a null statement");
                throw new 
PersistenceBrokerException("getInsertStatement returned a null 
statement");
            }

            broker.serviceStatementManager().bindInsert(stmt, cld, obj);
            if (logger.isDebugEnabled())
                logger.debug("executeInsert: " + stmt);
            stmt.executeUpdate();

            // Harvest any return values.
            this.harvestReturnValues(cld.getInsertProcedure(), obj, stmt);
--------
If the 'stmt' in the debug call is 'null', how could it have gotten 
past the null check earlier?    And why isnt' it throwing an NPE 
when the executeUpdate() is called?  I'm mystified.


--
Joe Germuska            
[EMAIL PROTECTED]  
http://blog.germuska.com    
      "Imagine if every Thursday your shoes exploded if you tied them 
the usual way.  This happens to us all the time with computers, and 
nobody thinks of complaining."
            -- Jef Raskin

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]