Menu

#388 ReplacementDataSet "ignores" its decorated DataSet's caseSensitiveTableNames setting

v2.5.*
closed-fixed
None
2.5.3
5
2016-05-30
2016-05-30
RafaelVS
No

The test below fails at current version of ReplacementDataSet.

public void testReplacementDataSetTableNamesCaseSensitive() throws Exception
{
    ReplacementDataSet dataSet = new ReplacementDataSet(new FlatXmlDataSetBuilder().setCaseSensitiveTableNames(true).build(new FileReader(FlatXmlDataSetTest.DATASET_FILE)));
    assertTrue( dataSet.isCaseSensitiveTableNames() );
}

Besides that, I noticed that most of IDataSet methods implemented by ReplacementDataSet are delegated to the decorated DataSet. The only method that is not delegated to the decorated DataSet is IDataSet.getTables() implemented by AbstractDataSet and here is where the problem arises, as the test below shows.

public void testReplacementDataSetTableNamesCaseSensitiveGetTables) throws Exception
{
    IDataSet originalDataSet = new FlatXmlDataSetBuilder().setCaseSensitiveTableNames(true).build(TestUtils.getFileReader("/xml/replacementDataSetCaseSensitive.xml"));
    ITable[] originalTables = originalDataSet.getTables();
    assertEquals( 2, originalTables.length );
    assertEquals( "TEST_TABLE", originalTables[0].getTableMetaData().getTableName() );
    assertEquals( "test_table", originalTables[1].getTableMetaData().getTableName() );
    assertEquals( "row 0 col 0", originalTables[0].getValue(0, "COLUMN0") );
    assertEquals( "row 1 col 0", originalTables[1].getValue(0, "COLUMN0") );

    //Below asserts must behave the same as the above ones.
    ReplacementDataSet replacementDataSet = new ReplacementDataSet( originalDataSet );
    ITable[] replacementTables = replacementDataSet.getTables();
    assertEquals( 2, replacementTables.length );
    assertEquals( "TEST_TABLE", replacementTables[0].getTableMetaData().getTableName() );
    assertEquals( "test_table", replacementTables[1].getTableMetaData().getTableName() );
    assertEquals( "row 0 col 0", replacementTables[0].getValue(0, "COLUMN0") );
    assertEquals( "row 1 col 0", replacementTables[1].getValue(0, "COLUMN0") );
}

Above test should have passed, but it throws the following exception: org.dbunit.database.AmbiguousTableNameException: TEST_TABLE

That's because tableNamesCaseSensitive is being ignored and the following code throws the exception:

public class OrderedTableNameMap {
    ...
    public void add(..) {
        ...
        // here is where original dataset's tableNamesCaseSensitive is being ignored.
        String tableNameCorrectedCase = this.getTableName(tableName);
        // prevent table name conflict
        if (this.containsTable(tableNameCorrectedCase))
        {
        throw new AmbiguousTableNameException(tableNameCorrectedCase);
        }
        ...
    }
}

To fix both tests, I simply added super( dataSet.isCaseSensitiveTableNames() ); to ReplacementeDataSet's constructor. By the way, should we care about validating if passed dataSet is null to avoid NullPointerException? I prefer being defensive, but I looked at other points of the code, like the constructor of CachedDataSet, and it doesn't do this validation, so I didn't bother.

I've attached a patch with the tests and the fix suggestion.

1 Attachments

Related

Bugs: #386

Discussion

  • Jeff Jensen

    Jeff Jensen - 2016-05-30
    • summary: ReplacementDataSet "ignores" its decorated DataSet's tableNamesCaseSensitive --> ReplacementDataSet "ignores" its decorated DataSet's caseSensitiveTableNames setting
     
  • Jeff Jensen

    Jeff Jensen - 2016-05-30
    • status: open --> closed-fixed
    • assigned_to: Jeff Jensen
    • Fixed Release: (not fixed) --> 2.5.3
     
  • Jeff Jensen

    Jeff Jensen - 2016-05-30

    Thank you for the tests and the fix! Committed.

    By the way, should we care about validating if passed dataSet is null to avoid NullPointerException? I prefer being defensive, but I looked at other points of the code, like the constructor of CachedDataSet, and it doesn't do this validation, so I didn't bother.

    Agreed, I prefer defensive checks too. Lots of this code is very old and not-so-defensive, as you mentioned.

     

    Last edit: Jeff Jensen 2016-05-30

Log in to post a comment.