Weird comparison failure for SortedTable with useComparable=true! But why?

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

Weird comparison failure for SortedTable with useComparable=true! But why?

Kimbrough, Kerry

With DbUnit 2.4.7, I’m seeing this failure from Assertion.assertEquals( ITable, ITable, FailureHandler):

 

Failure value (table=CO_EXTERNAL_ID, row=1, col=EXTERNAL_ID, COMPANY_ID=11600000000000, SOURCE_ID=26, EXTERNAL_ID=051957769) expected:<051957769> but was:<104169>

 

This is saying something weird: looking at the record for which EXTERNAL_ID=051957769, the actual value of col=EXTERNAL_ID is 104169. Huh?

 

At any rate, I don’t know why there’s any failure at all. Looking at the actual contents of the Oracle database-under-test, I can see that the table contains the expected record set. It must be a bogus failure due different orders for expected and actual ITable rows. But I’m using exactly the same order for both of them.

 

Both the expected and actual ITable objects are decorated as a SortedTable before comparison. Both SortedTable instances have useComparable=true. Both SortedTable instances use exactly the same sort columns -- specifically, the actual.getTableMetaData().getPrimaryKeys() columns, which in this case is [COMPANY_ID (number), SOURCE_ID (number), EXTERNAL_ID ( varchar)]. How can the ordering possibly be different?

 

And yet the failure is what I might expect if “comparable” ordering is used for one table but “string” ordering is used for the other. How could this be?

 

BTW, I experimented with changing to useComparable=false for both expected and actual SortedTable instances. The failure disappeared! But why?

 

Any advice would be much appreciated.

 

Regards,

Kerry Kimbrough

 

 

 

 


------------------------------------------------------------------------------
Enable your software for Intel(R) Active Management Technology to meet the
growing manageability and security demands of your customers. Businesses
are taking advantage of Intel(R) vPro (TM) technology - will your software
be a part of the solution? Download the Intel(R) Manageability Checker
today! http://p.sf.net/sfu/intel-dev2devmar
_______________________________________________
dbunit-user mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/dbunit-user
Reply | Threaded
Open this post in threaded view
|

Re: Weird comparison failure for SortedTable with useComparable=true! But why?

John Hurst-2
Hello,

I don't know the full context of your problem.

But, just an idea: is it possible that the leading zero in external_id = 051957769 is causing an inconsistent ordering when you change the ordering setting? I.e., numerically 051957769 comes after 104169, but lexicographically it comes before.

Regards

John Hurst

Wellington, New Zealand

On Wed, Mar 23, 2011 at 11:05 AM, Kimbrough, Kerry <[hidden email]> wrote:

With DbUnit 2.4.7, I’m seeing this failure from Assertion.assertEquals( ITable, ITable, FailureHandler):

 

Failure value (table=CO_EXTERNAL_ID, row=1, col=EXTERNAL_ID, COMPANY_ID=11600000000000, SOURCE_ID=26, EXTERNAL_ID=051957769) expected:<051957769> but was:<104169>

 

This is saying something weird: looking at the record for which EXTERNAL_ID=051957769, the actual value of col=EXTERNAL_ID is 104169. Huh?

 

At any rate, I don’t know why there’s any failure at all. Looking at the actual contents of the Oracle database-under-test, I can see that the table contains the expected record set. It must be a bogus failure due different orders for expected and actual ITable rows. But I’m using exactly the same order for both of them.

 

Both the expected and actual ITable objects are decorated as a SortedTable before comparison. Both SortedTable instances have useComparable=true. Both SortedTable instances use exactly the same sort columns -- specifically, the actual.getTableMetaData().getPrimaryKeys() columns, which in this case is [COMPANY_ID (number), SOURCE_ID (number), EXTERNAL_ID ( varchar)]. How can the ordering possibly be different?

 

And yet the failure is what I might expect if “comparable” ordering is used for one table but “string” ordering is used for the other. How could this be?

 

BTW, I experimented with changing to useComparable=false for both expected and actual SortedTable instances. The failure disappeared! But why?

 

Any advice would be much appreciated.

 

Regards,

Kerry Kimbrough

 

 

 

 


------------------------------------------------------------------------------
Enable your software for Intel(R) Active Management Technology to meet the
growing manageability and security demands of your customers. Businesses
are taking advantage of Intel(R) vPro (TM) technology - will your software
be a part of the solution? Download the Intel(R) Manageability Checker
today! http://p.sf.net/sfu/intel-dev2devmar
_______________________________________________
dbunit-user mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/dbunit-user




--
Life is interfering with my game

------------------------------------------------------------------------------
Enable your software for Intel(R) Active Management Technology to meet the
growing manageability and security demands of your customers. Businesses
are taking advantage of Intel(R) vPro (TM) technology - will your software
be a part of the solution? Download the Intel(R) Manageability Checker
today! http://p.sf.net/sfu/intel-dev2devmar
_______________________________________________
dbunit-user mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/dbunit-user
Reply | Threaded
Open this post in threaded view
|

Re: Weird comparison failure for SortedTable with useComparable=true! But why?

Sébastien LE CALLONNEC
In reply to this post by Kimbrough, Kerry
Hi Kerry,

On 22/03/2011 22:05, Kimbrough, Kerry wrote:
> And yet the failure is what I might expect if “comparable” ordering is
> used for one table but “string” ordering is used for the other. How
> could this be?
>
> *//*
>
> BTW, I experimented with changing to useComparable=false for both
> expected and actual SortedTable instances. The failure disappeared! But why?

Assuming you are using an xml file to define your expected dataset, this
is more than likely caused by the fact that the columns in the expected
dataset have a datatype StringDataType, so the sorting logic is different.

When using useComparable=false, columns are sorted assuming they are all
strings, hence the error disappears.

I am not certain there isn’t a bug here though, as I thought by default
unknown types were compared as strings...


Regards,
Sébastien.

------------------------------------------------------------------------------
Enable your software for Intel(R) Active Management Technology to meet the
growing manageability and security demands of your customers. Businesses
are taking advantage of Intel(R) vPro (TM) technology - will your software
be a part of the solution? Download the Intel(R) Manageability Checker
today! http://p.sf.net/sfu/intel-dev2devmar
_______________________________________________
dbunit-user mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/dbunit-user
Reply | Threaded
Open this post in threaded view
|

Re: Weird comparison failure for SortedTable with useComparable=true! But why?

Kimbrough, Kerry
Thanks, Sebastien. Your explanation makes sense to me.

I thought I had avoided such a problem, because I created both the expected SortedTable (derived, as you guessed, from an XML file) and the actual SortedTable (derived from the database) with exactly the same array of sort Column instances, using Column objects extracted from the actual ITable object. These Column objects would have the true column data types.

But perhaps the expected SortedTable used only the column names and ignored these column types. If so, that seems like a defect. But I haven't checked the source code to confirm this theory.

Regards,
Kerry

-----Original Message-----
From: Sébastien Le Callonnec [mailto:[hidden email]]
Sent: Wednesday, March 23, 2011 3:19 AM
To: [hidden email]
Subject: Re: [dbunit-user] Weird comparison failure for SortedTable with useComparable=true! But why?

Hi Kerry,

On 22/03/2011 22:05, Kimbrough, Kerry wrote:
> And yet the failure is what I might expect if "comparable" ordering is
> used for one table but "string" ordering is used for the other. How
> could this be?
>
> *//*
>
> BTW, I experimented with changing to useComparable=false for both
> expected and actual SortedTable instances. The failure disappeared! But why?

Assuming you are using an xml file to define your expected dataset, this
is more than likely caused by the fact that the columns in the expected
dataset have a datatype StringDataType, so the sorting logic is different.

When using useComparable=false, columns are sorted assuming they are all
strings, hence the error disappears.

I am not certain there isn't a bug here though, as I thought by default
unknown types were compared as strings...


Regards,
Sébastien.

------------------------------------------------------------------------------
Enable your software for Intel(R) Active Management Technology to meet the
growing manageability and security demands of your customers. Businesses
are taking advantage of Intel(R) vPro (TM) technology - will your software
be a part of the solution? Download the Intel(R) Manageability Checker
today! http://p.sf.net/sfu/intel-dev2devmar
_______________________________________________
dbunit-user mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/dbunit-user
Reply | Threaded
Open this post in threaded view
|

Re: Weird comparison failure for SortedTable with useComparable=true! But why?

Sébastien LE CALLONNEC
Hi Kerry,

On 23/03/2011 13:56, Kimbrough, Kerry wrote:
> Thanks, Sebastien. Your explanation makes sense to me.

Reading my explanation again, it looks like I missed a few words though:
I meant to say that the datatype of the columns in the expected column
is UnknownDataType, whereas the datatype of the columns in the actual db
is StringDataType.

However, looking into this a bit further, I can’t seem to reproduce the
problem.  As I thought, it does look like UnknownDataType compares as
strings.

Would you be able to send a small test case highlighting this issue so
that we can have a look?


Thanks,
Seb

------------------------------------------------------------------------------
Enable your software for Intel(R) Active Management Technology to meet the
growing manageability and security demands of your customers. Businesses
are taking advantage of Intel(R) vPro (TM) technology - will your software
be a part of the solution? Download the Intel(R) Manageability Checker
today! http://p.sf.net/sfu/intel-dev2devmar
_______________________________________________
dbunit-user mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/dbunit-user