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]
-------------------------------------------------
