incubator-graffito-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Martin Maisey <>
Subject Re: MySQL/InnoDB build issues
Date Wed, 08 Jun 2005 22:52:00 GMT
Hi Christophe,

Thanks for the quick reply!

Christophe Lombart wrote:

>Yes, this unit test check the engine transactionnal behavior.
>Now, I understand why Roy, Herman and you cannot build Graffito. Old
>MySql version can provide transactionnal issues if it is not well
>I recommend to use MySql 4.1.12 / MySql connection 3.1.8.
>I will update the Graffito site with this info. 
>I'm using this MySql version on XP and I didn't this kind of issues.
>Can you try with MySql 4.1.12/mysql connection 3.1.8 ? We should check
>in the MySql doc what are the differencies between 4.0.x and 4.1.x

I've upgraded to the 4.1.12a binary package and now get a clean build 
when using InnoDB - thanks. I accidentally picked up the older version 
of MySQL rather than the newer, but at least it's highlighted the 

For others hoping to get going, I used the following settings in the 
instance configuration wizard:

 * Developer machine
 * Transactional Database Only
 * Tablespaces on installation path
 * 30 concurrent connections
 * TCP/IP networking enabled
 * UTF8 character set support
 * Install as Windows service
 * Include Bin Directory in Windows PATH

Although I think any settings except selecting "non-transactional 
database only" would work, as the default table type is now InnoDB 
rather than MyISAM in all other cases (since late 4.1.x) and it's this 
new version of InnoDB that fixes the problem.

I've played around with manually executing the SQL, and found the 
apparent reason for the difference between versions: 4.1.12 seems to 
automatically create the index required when creating the foreign key 
constraint - as mentioned earlier, the 4.0.x version I had didn't do 
this and just errors if the index doesn't exist. The MySQL docs still 
describe the 4.0.x behaviour and are out of date. I have quickly checked 
the changelogs for MySQL and InnoDB between the two versions and can't 
see anything specifically referencing this change - however, there have 
been _lots_ of other changes around InnoDB foreign keys, so one of these 
may have had this side effect. (or I could have missed something...)

I still think it might be worth adding explicitly defined indexes in the 
Graffito schema, though. This would allow Graffito to work with 4.0.x 
with InnoDB, and also ensure that performance is reasonable on other 
databases that don't rely on and therefore automatically create indexes. 
This includes Oracle and MS SQL Server at least from a quick Google.

Again, I'm happy to take this on and test with MySQL 4.0.x if you're 
willing to commit the changes for me. If you want, I can also give you a 
patch for the getting started website page with updates based on my 

>Thanks you very much for your tests & feedbacks.
No problems at all - happy to help however I can. I'll try the JetSpeed 
deployment tomorrow.



View raw message