Good advice and thanks, and the latest tests I've just done are all with the 3.0.17 drivers, so the 3.1.x driver issues aren't coming into play. I'm just really wondering why /how castor is acting different internally when it really shouldn't matter. (note, not blaming castor because I dont think thats the issue)
-Nick On 6/22/05, Werner Guttmann <[EMAIL PROTECTED]> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Nick, > > mySQL's Connector/J isn't really a stable environment to work with, > given the number of exciting hours I have wasted to debug assumed Castor > issues that turned out to be incompatibilities between driver releases. > > Personally, I am using mySQL as my main development platform, and I have > got three installations on there PCs (switching between them all time). > Here's a brief summary of what I learned. > > a) Using mySQL server release 4.0.x or 4.1.x is fine. I have once tried > to use mySQL 5.0 with Castor, but quickly ran into issues I believe are > a result of being too early. > b) When using mySQL server 4.x.y, make sure you don't use Connector/J > 3.1.x, as it does cause problems in some areas (most noticeably around > prepared statements and column result types). > c) In other words, with mySQL server 4.x.y, use Connector/J 3.0.16 > unless there something broken that you require to be fixed. So far, I > still have to run into problems with 3.0.16, but let's knock on wood. > > Regards > Werner > > Nick Stuart wrote: > > Ok, found an odd one here. Nothing to do with Castor, but I think it > > should be known. I'm using mysql 4.1.11 on my laptop here for dev > > purposes, and there seems to be a problem with the reported fields > > coming back from mysql. > > > > In SQLEngine around line 963 (the for loop) I get the following exception: > > > > Caused by: java.lang.ArrayIndexOutOfBoundsException: 6 > > at org.exolab.castor.jdo.engine.SQLEngine.store(SQLEngine.java:964) > > at org.exolab.castor.jdo.engine.SQLEngine.store(SQLEngine.java:826) > > at org.exolab.castor.persist.ClassMolder.store(ClassMolder.java:1622) > > at org.exolab.castor.persist.LockEngine.store(LockEngine.java:760) > > at > > org.exolab.castor.persist.TransactionContext.prepare(TransactionContext.java:1598) > > ... 47 more > > > > The following SQL is being generated: > > 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=? > > > > which correctly shows the 6 fields needed for StdSystem (not sure why > > the join is there but it is). Anyways, I threw some extra logging in > > there and got this: > > > > DEBUG http-8084-Processor22 org.exolab.castor.jdo.engine.SQLEngine - > > Got a total of 22 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 > > <exception here> > > > > Whats odd is the 22 there is from fields.length, thats how many fields > > are reported as being needed/returned...hmm, thats not quite right!! I > > dont think this is a connector/j issue. Tried both 3.1 and 3.0 series, > > both with the same results. AND if I change the config around to use > > another database, it works perfectly fine (all the same libs/src > > everything)! > > > > Anyone else seen any thing like this?!? Guess its time to update > > MySQL on my laptop. :( > > > > -Nick > > > > ------------------------------------------------- > > If you wish to unsubscribe from this list, please > > send an empty message to the following address: > > > > [EMAIL PROTECTED] > > ------------------------------------------------- > > > > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.1 (MingW32) > Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org > > iD8DBQFCubi8yTCBEXSJgmcRAgxdAJwKbcSnMIJgesAXFEu+IIArfJO6tgCfXGof > uRKhb1Z1xcYNOoDkZc6pbdY= > =oC4f > -----END PGP SIGNATURE----- > > > ------------------------------------------------- > 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] -------------------------------------------------
