Nick, can you still switch to 3.0.16, as I remember upgrading within the 3.0.x series caused problems as well.
Werner Nick Stuart wrote: > 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: > > 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] >>------------------------------------------------- > > > ------------------------------------------------- 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] -------------------------------------------------
