Version is the 0.9.7 release. I was trying to get a CVS copy, but it
wouldn't let me do a checkout, something about obtaining a lock from
the test directory. For the extra log info:
[DEBUG] org.exolab.castor.jdo.engine.SQLEngine.store(SQLEngine.java:839)
org.exolab.castor.jdo.engine.SQLEngine - Storing class:
com.vort.beans.StdSystem using SQL:
[EMAIL PROTECTED]
[DEBUG] org.exolab.castor.jdo.engine.SQLEngine.store(SQLEngine.java:886)
org.exolab.castor.jdo.engine.SQLEngine - The identity id was set to a
value of 214
[DEBUG] org.exolab.castor.jdo.engine.SQLEngine.store(SQLEngine.java:921)
org.exolab.castor.jdo.engine.SQLEngine - The field systemName was set
to a value of WQS 412
[DEBUG] org.exolab.castor.jdo.engine.SQLEngine.store(SQLEngine.java:921)
org.exolab.castor.jdo.engine.SQLEngine - The field zipCode was set to
a value of 56304
[DEBUG] org.exolab.castor.jdo.engine.SQLEngine.store(SQLEngine.java:921)
org.exolab.castor.jdo.engine.SQLEngine - The field projectId was set
to a value of 42
[DEBUG] org.exolab.castor.jdo.engine.SQLEngine.store(SQLEngine.java:921)
org.exolab.castor.jdo.engine.SQLEngine - The field sized was set to a
value of 1
[DEBUG] org.exolab.castor.jdo.engine.SQLEngine.store(SQLEngine.java:921)
org.exolab.castor.jdo.engine.SQLEngine - The field metric was set to a
value of 0
[DEBUG] org.exolab.castor.jdo.engine.SQLEngine.store(SQLEngine.java:929)
org.exolab.castor.jdo.engine.SQLEngine - Storing class:
com.vort.beans.StdSystem using SQL:
[EMAIL PROTECTED]
[DEBUG] org.exolab.castor.jdo.engine.SQLEngine.store(SQLEngine.java:941)
org.exolab.castor.jdo.engine.SQLEngine - Storing class:
com.vort.beans.StdSystem using SQL: SELECT
prjsystems.systemName,prjsystems.zipCode,prjsystems.projectId,prjsystems.sized,prjsystems.metric,prjsiteinfo.id
FROM prjsystems LEFT OUTER JOIN prjsiteinfo ON
prjsystems.id=prjsiteinfo.systemId WHERE prjsystems.id=?
[DEBUG] org.exolab.castor.jdo.engine.SQLEngine.store(SQLEngine.java:962)
org.exolab.castor.jdo.engine.SQLEngine - Got a total of 6 to
check/store.
[DEBUG] org.exolab.castor.jdo.engine.SQLEngine.store(SQLEngine.java:964)
org.exolab.castor.jdo.engine.SQLEngine - Getting field value for
systemName
[DEBUG] org.exolab.castor.jdo.engine.SQLEngine.store(SQLEngine.java:964)
org.exolab.castor.jdo.engine.SQLEngine - Getting field value for
zipCode
[DEBUG] org.exolab.castor.jdo.engine.SQLEngine.store(SQLEngine.java:964)
org.exolab.castor.jdo.engine.SQLEngine - Getting field value for
projectId
[DEBUG] org.exolab.castor.jdo.engine.SQLEngine.store(SQLEngine.java:964)
org.exolab.castor.jdo.engine.SQLEngine - Getting field value for sized
[DEBUG] org.exolab.castor.jdo.engine.SQLEngine.store(SQLEngine.java:964)
org.exolab.castor.jdo.engine.SQLEngine - Getting field value for
metric
[DEBUG] org.exolab.castor.jdo.engine.SQLEngine.store(SQLEngine.java:964)
org.exolab.castor.jdo.engine.SQLEngine - Getting field value for id
[ERROR] org.exolab.castor.jdo.engine.DatabaseImpl.commit(DatabaseImpl.java:521)
org.exolab.castor.jdo.engine.DatabaseImpl - This transaction has been
aborted and rolled back: Nested error:
java.lang.ArrayIndexOutOfBoundsException: 6: 6
org.exolab.castor.jdo.TransactionAbortedException: Nested error:
java.lang.ArrayIndexOutOfBoundsException: 6: 6
at
org.exolab.castor.persist.TransactionContext.prepare(TransactionContext.java:1653)
at
org.exolab.castor.jdo.engine.DatabaseImpl.commit(DatabaseImpl.java:518)
Remember, that whole part at the bottom with the "Getting field value
for..." is never shown when I go against a 4.0 database. Also, I added
2 lines for debugging:
[962]_log.debug("Got a total of " + _fields.length + " to
check/store."); //but fields.length = 22
[963]for(int i = 0; i < fields.length; i++){
[964] _log.debug("Getting field value for " + _fields[i].columns[0].name);
On 6/22/05, Werner Guttmann <[EMAIL PROTECTED]> wrote:
> Nick,
>
> what version of Castor are you actually using ? And can you please
> configure your logging system (assuming it's Log4J) to prepend each line
> with the location where the actual output is generated. I have a bit of
> an idea, but need more detailed log entries.
>
> Werner
>
> Nick Stuart wrote:
> > To follow up on this strange acting stuff. So, when I am running
> > against a 4.0 mysql server I see the following in the log:
> >
> > DEBUG http-8084-Processor24 org.exolab.castor.jdo.engine.SQLEngine -
> > Storing class: com.vort.beans.StdSystem using SQL:
> > [EMAIL PROTECTED]
> > DEBUG http-8084-Processor24 org.exolab.castor.jdo.engine.SQLEngine -
> > The identity id was set to a value of 214
> > DEBUG http-8084-Processor24 org.exolab.castor.jdo.engine.SQLEngine -
> > The field systemName was set to a value of WQS 412
> > DEBUG http-8084-Processor24 org.exolab.castor.jdo.engine.SQLEngine -
> > The field zipCode was set to a value of 04116
> > DEBUG http-8084-Processor24 org.exolab.castor.jdo.engine.SQLEngine -
> > The field projectId was set to a value of 42
> > DEBUG http-8084-Processor24 org.exolab.castor.jdo.engine.SQLEngine -
> > The field sized was set to a value of 1
> > DEBUG http-8084-Processor24 org.exolab.castor.jdo.engine.SQLEngine -
> > The field metric was set to a value of 0
> > DEBUG http-8084-Processor24 org.exolab.castor.jdo.engine.SQLEngine -
> > Storing class: com.vort.beans.StdSystem using SQL:
> > [EMAIL PROTECTED]
> > DEBUG http-8084-Processor24 org.exolab.castor.jdo.engine.SQLEngine -
> > Storing class: com.vort.vortechs.beans.VortechsDims using SQL:
> > [EMAIL PROTECTED]
> >
> > And then it moves on to the next object.
> > This shows its using a prepared statement which is fine and dandy and
> > shows the fields being updated, blah blah. Here is what I see running
> > against a 4.1 database (local):
> >
> > DEBUG http-8084-Processor22 org.exolab.castor.jdo.engine.SQLEngine -
> > Storing class: com.vort.beans.StdSystem using SQL:
> > [EMAIL PROTECTED]
> > DEBUG http-8084-Processor22 org.exolab.castor.jdo.engine.SQLEngine -
> > The identity id was set to a value of 214
> > DEBUG http-8084-Processor22 org.exolab.castor.jdo.engine.SQLEngine -
> > The field systemName was set to a value of WQS 412
> > DEBUG http-8084-Processor22 org.exolab.castor.jdo.engine.SQLEngine -
> > The field zipCode was set to a value of 56304
> > DEBUG http-8084-Processor22 org.exolab.castor.jdo.engine.SQLEngine -
> > The field projectId was set to a value of 42
> > DEBUG http-8084-Processor22 org.exolab.castor.jdo.engine.SQLEngine -
> > The field sized was set to a value of 1
> > DEBUG http-8084-Processor22 org.exolab.castor.jdo.engine.SQLEngine -
> > The field metric was set to a value of 0
> > DEBUG http-8084-Processor22 org.exolab.castor.jdo.engine.SQLEngine -
> > Storing class: com.vort.beans.StdSystem using SQL:
> > [EMAIL PROTECTED]
> > <!----NEVER SEE ANY OF THIS AGAINST THE 4.0 DATABASE, WHY-->
> > DEBUG http-8084-Processor22 org.exolab.castor.jdo.engine.SQLEngine -
> > Storing class: com.vort.beans.StdSystem using SQL: SELECT
> > prjsystems.systemName,prjsystems.zipCode,prjsystems.projectId,prjsystems.sized,prjsystems.metric,prjsiteinfo.id
> > FROM prjsystems LEFT OUTER JOIN prjsiteinfo ON
> > prjsystems.id=prjsiteinfo.systemId WHERE prjsystems.id=?
> > DEBUG http-8084-Processor22 org.exolab.castor.jdo.engine.SQLEngine -
> > Got a total of 6 to check/store.
> > DEBUG http-8084-Processor22 org.exolab.castor.jdo.engine.SQLEngine -
> > Getting field value for systemName
> > DEBUG http-8084-Processor22 org.exolab.castor.jdo.engine.SQLEngine -
> > Getting field value for zipCode
> > DEBUG http-8084-Processor22 org.exolab.castor.jdo.engine.SQLEngine -
> > Getting field value for projectId
> > DEBUG http-8084-Processor22 org.exolab.castor.jdo.engine.SQLEngine -
> > Getting field value for sized
> > DEBUG http-8084-Processor22 org.exolab.castor.jdo.engine.SQLEngine -
> > Getting field value for metric
> > DEBUG http-8084-Processor22 org.exolab.castor.jdo.engine.SQLEngine -
> > Getting field value for id
> > ERROR http-8084-Processor22 org.exolab.castor.jdo.engine.DatabaseImpl
> > - This transaction has been aborted and rolled back: Nested error:
> > java.lang.ArrayIndexOutOfBoundsException: 6: 6
> > org.exolab.castor.jdo.TransactionAbortedException: Nested error:
> > java.lang.ArrayIndexOutOfBoundsException: 6: 6
> > at
> > org.exolab.castor.persist.TransactionContext.prepare(TransactionContext.java:1653)
> > at
> > org.exolab.castor.jdo.engine.DatabaseImpl.commit(DatabaseImpl.java:518)
> >
> >
> > Why the differences between just the DB versions?! I'm not sure whats
> > going on here now and am really confused. Castor doesn't check
> > anything out about what version of the database your connected to or
> > anything right?!
> >
> > Next step is going to be to try this out on a fresh install of a
> > database on another machine and see where I get.
> >
> > -Nick (really confused at this point) S
> >
> > -------------------------------------------------
> > If you wish to unsubscribe from this list, please
> > send an empty message to the following address:
> >
> > [EMAIL PROTECTED]
> > -------------------------------------------------
> >
> >
>
>
> -------------------------------------------------
> If you wish to unsubscribe from this list, please
> send an empty message to the following address:
>
> [EMAIL PROTECTED]
> -------------------------------------------------
>
>
-------------------------------------------------
If you wish to unsubscribe from this list, please
send an empty message to the following address:
[EMAIL PROTECTED]
-------------------------------------------------
