the default behaviour is to ignore case which is why every tablename is the "toUpperCase()"ed in dbunit. You can probably fix your problem by setting the feature "http://www.dbunit.org/features/caseSensitiveTableNames" to "true" on the DatabaseConfig or by invoking a constructor having set the "caseSensitiveTableNames=true" (for example "public DatabaseDataSet(IDatabaseConnection connection, boolean caseSensitiveTableNames)").
Regards,
matthias
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I think I'm running into the same problem. When MySQL is running on a Windows box, everything works fine. When MySQL runs on a Linux box, NoSuchTableException is thrown for every table reference because DBUnit is looking for capitalized table names.
This (broken) behavior happens consistently with versions [2.4.0, 2.4.3]. v2.3.0 (and all previous versions) work correctly with respect to table name capitalization.
I tried the FEATURE_CASE_SENSITIVE_TABLE_NAMES option but it didn't seem to have any effect. I supplied both the literal true and the string "true", neither changed the outcome.
As Matthias already knows, I'm an advocate for retaining previous behavior, especially when that behavior worked out of the box without requiring additional configuration.
sorry for the long delay.
I think you made one mistake in your testcase: the caseSensitiveTableNames is a feature and not a property (and features are always primitive booleans). So please try the following and let me know if it works:
Personally, I'd like to see it work out the box once again. While I think it's a good idea in general, I'm also a little selfish because I have a open source test support project that uses dbunit (http://blog.carbonfive.com/2008/07/testing/database-testing-with-spring-25-and-dbunit) and supports a variety of db types. The previous functionality seemed to work out of the box across the supported db types across platforms. While I can fix MySQL on Linux by specifying this feature, it's better when it just works.
What instigated the change with 2.4 that altered the previous behavior?
Christian
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
the altered behavior in 2.4 was not intended to have the side-effect that you experience. The cause for this change is that I introduced the new class "OrderedTableNameMap" which I intended to be the only place where case-sensitivity is specified. The reason for this one again was that since 2.2 or 2.1 it was not possible anymore to have case sensitive table names with a DatabaseDataSet. To support both I introduced this change. I definitely liked the pre 2.2/2.1 implementation more where DataSets have been case-sensitive by default and case-insensitivity was achieved by a decorator dataset. Well, so much to the past...(see bug report #1214252 for a long discussion about this)
Now to my findings:
I suspect that DatabaseDataSet#getTableMetaData causes your problem. Could you try to change the line 285 (current trunk)
// current version (probably causing your problem)
metaData = new DatabaseTableMetaData(_tableMap.getTableName(tableName), _connection, true, super.isCaseSensitiveTableNames());
// This should the work for you again
metaData = new DatabaseTableMetaData(tableName, _connection, true, super.isCaseSensitiveTableNames());
There are some things to look at in order to fix this bug (there are some classes involved and some unit tests broken when I change the line mentioned above).
Regards,
matthias
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I applied 2517257-nonmodified-tablename.patch to trunk and ran my test and it passed *without* having to set FEATURE_CASE_SENSITIVE_TABLE_NAMES. That's great.
Thanks,
Christian
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thanks for testing, Christian! The version I committed has the same upper/lowerCase handling now for tableNames (DatabaseTableMetaData) and schemaNames (DatabaseConnection). So I'll close this issue.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi there,
the default behaviour is to ignore case which is why every tablename is the "toUpperCase()"ed in dbunit. You can probably fix your problem by setting the feature "http://www.dbunit.org/features/caseSensitiveTableNames" to "true" on the DatabaseConfig or by invoking a constructor having set the "caseSensitiveTableNames=true" (for example "public DatabaseDataSet(IDatabaseConnection connection, boolean caseSensitiveTableNames)").
Regards,
matthias
I think I'm running into the same problem. When MySQL is running on a Windows box, everything works fine. When MySQL runs on a Linux box, NoSuchTableException is thrown for every table reference because DBUnit is looking for capitalized table names.
This (broken) behavior happens consistently with versions [2.4.0, 2.4.3]. v2.3.0 (and all previous versions) work correctly with respect to table name capitalization.
I tried the FEATURE_CASE_SENSITIVE_TABLE_NAMES option but it didn't seem to have any effect. I supplied both the literal true and the string "true", neither changed the outcome.
As Matthias already knows, I'm an advocate for retaining previous behavior, especially when that behavior worked out of the box without requiring additional configuration.
I've updated my previous test application to reflect this problem. It can be found at: http://svn.carbonfive.com/public/christian/dbunit-mysql-issue/trunk/
Hi Christian,
sorry for the long delay.
I think you made one mistake in your testcase: the caseSensitiveTableNames is a feature and not a property (and features are always primitive booleans). So please try the following and let me know if it works:
tester.getConnection().getConfig().setFeature(DatabaseConfig.FEATURE_CASE_SENSITIVE_TABLE_NAMES, true);
nevertheless I will investigate this in detail.
Regards,
matthias
Matthias,
You're right... that did the trick.
Personally, I'd like to see it work out the box once again. While I think it's a good idea in general, I'm also a little selfish because I have a open source test support project that uses dbunit (http://blog.carbonfive.com/2008/07/testing/database-testing-with-spring-25-and-dbunit) and supports a variety of db types. The previous functionality seemed to work out of the box across the supported db types across platforms. While I can fix MySQL on Linux by specifying this feature, it's better when it just works.
What instigated the change with 2.4 that altered the previous behavior?
Christian
Hi Christian,
the altered behavior in 2.4 was not intended to have the side-effect that you experience. The cause for this change is that I introduced the new class "OrderedTableNameMap" which I intended to be the only place where case-sensitivity is specified. The reason for this one again was that since 2.2 or 2.1 it was not possible anymore to have case sensitive table names with a DatabaseDataSet. To support both I introduced this change. I definitely liked the pre 2.2/2.1 implementation more where DataSets have been case-sensitive by default and case-insensitivity was achieved by a decorator dataset. Well, so much to the past...(see bug report #1214252 for a long discussion about this)
Now to my findings:
I suspect that DatabaseDataSet#getTableMetaData causes your problem. Could you try to change the line 285 (current trunk)
// current version (probably causing your problem)
metaData = new DatabaseTableMetaData(_tableMap.getTableName(tableName), _connection, true, super.isCaseSensitiveTableNames());
// This should the work for you again
metaData = new DatabaseTableMetaData(tableName, _connection, true, super.isCaseSensitiveTableNames());
There are some things to look at in order to fix this bug (there are some classes involved and some unit tests broken when I change the line mentioned above).
Regards,
matthias
2517257-nonmodified-tablename.patch
Hi there,
I attached a patch and want to ask you to test whether it fixes your problem. It can be applied to the current trunk.
Regards,
matthias
File Added: 2517257-nonmodified-tablename.patch
Matthias,
I applied 2517257-nonmodified-tablename.patch to trunk and ran my test and it passed *without* having to set FEATURE_CASE_SENSITIVE_TABLE_NAMES. That's great.
Thanks,
Christian
Hi there,
I fixed this bug and committed my changes to rev. 961/trunk (for the upcoming 2.4.4 release). Could you please test the latest build (see http://parabuild.viewtier.com:8080/parabuild/index.htm?view=detailed&buildid=30 ) and let me know if it works for you?
Thanks and best regards,
matthias
Thanks for testing, Christian! The version I committed has the same upper/lowerCase handling now for tableNames (DatabaseTableMetaData) and schemaNames (DatabaseConnection). So I'll close this issue.