You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@empire-db.apache.org by Rainer Döbele <do...@esteam.de> on 2011/10/10 16:51:12 UTC
Failure of PreparedStatementTest
Hi Francis,
it took me a while to find the cause for this bug.
Obviously it’s the following line in the test that is the problem:
assertEquals(id, r.getValue(DEP.ID));
This assert fails if id is int and getValue() returns a long.
Strangely it does not fail if id is a long and you write:
assertEquals(id, r.getInt(DEP.ID));
which will also compare a long with an int, but the other way round.
In both cases the value is 1 - hence there are effectively equal.
(Is this a bug in JUnit?)
The reason why this error occurs now, is that previously in HSQLDB all integer columns were declared as BIGINT.
However all other drivers created integer columns as INT.
Now, there is a way to specify the size in the table definition:
// DEFAULT (usually 4 bytes = 32bit)
DEPARTMENT_ID = addColumn("DEPARTMENT_ID", DataType.INTEGER, DEFAULT, true);
// SMALLINT (usually 2 bytes = 16bit)
DEPARTMENT_ID = addColumn("DEPARTMENT_ID", DataType.INTEGER, SMALLINT, true);
// BIGINT (usually 8 bytes = 64bit)
DEPARTMENT_ID = addColumn("DEPARTMENT_ID", DataType.INTEGER, BIGINT, true);
This is consistent over all drivers.
However the exact interpretation of INT, SMALLINT an BIGINT is left to the database.
That also solves EMPIREDB-105.
Regards
Rainer
> from: francisdb@apache.org [mailto:francisdb@apache.org]
> to: empire-db-commits@incubator.apache.org
> re: svn commit: r1180840 - /incubator/empire-db/trunk/empire-
> db/src/test/java/org/apache/empire/db/PreparedStatementTest.java
>
> Author: francisdb
> Date: Mon Oct 10 09:27:18 2011
> New Revision: 1180840
>
> URL: http://svn.apache.org/viewvc?rev=1180840&view=rev
> Log:
> This id field is now int instead of long (is this expected?)
>
> Modified:
> incubator/empire-db/trunk/empire-
> db/src/test/java/org/apache/empire/db/PreparedStatementTest.java
>
> Modified: incubator/empire-db/trunk/empire-
> db/src/test/java/org/apache/empire/db/PreparedStatementTest.java
> URL: http://svn.apache.org/viewvc/incubator/empire-db/trunk/empire-
> db/src/test/java/org/apache/empire/db/PreparedStatementTest.java?rev=
> 1180840&r1=1180839&r2=1180840&view=diff
> ==========================================================
> ====================
> --- incubator/empire-db/trunk/empire-
> db/src/test/java/org/apache/empire/db/PreparedStatementTest.java
> (original)
> +++ incubator/empire-db/trunk/empire-
> db/src/test/java/org/apache/empire/db/PreparedStatementTest.java Mon
> Oct 10 09:27:18 2011
> @@ -54,7 +54,7 @@ public class PreparedStatementTest{
> department.setValue(db.DEPARTMENT.BUSINESS_UNIT, "test");
> department.update(conn);
>
> - long id = department.getInt(db.DEPARTMENT.ID);
> + int id = department.getInt(db.DEPARTMENT.ID);
> assertTrue("Department add failed", id > 0);
>
>
>
Re: Failure of PreparedStatementTest
Posted by Francis De Brabandere <fr...@gmail.com>.
On Mon, Oct 10, 2011 at 4:51 PM, Rainer Döbele <do...@esteam.de> wrote:
> Hi Francis,
>
> it took me a while to find the cause for this bug.
> Obviously it’s the following line in the test that is the problem:
> assertEquals(id, r.getValue(DEP.ID));
> This assert fails if id is int and getValue() returns a long.
>
> Strangely it does not fail if id is a long and you write:
> assertEquals(id, r.getInt(DEP.ID));
> which will also compare a long with an int, but the other way round.
>
> In both cases the value is 1 - hence there are effectively equal.
> (Is this a bug in JUnit?)
Don't think this is a bug. I just think that assertEquals(int, int)
has a specific behavior that assertEquals(Object, Object) does not
have. What does java Long#equals(Integer) do?
Cheers,
Francis
>
> The reason why this error occurs now, is that previously in HSQLDB all integer columns were declared as BIGINT.
> However all other drivers created integer columns as INT.
> Now, there is a way to specify the size in the table definition:
>
> // DEFAULT (usually 4 bytes = 32bit)
> DEPARTMENT_ID = addColumn("DEPARTMENT_ID", DataType.INTEGER, DEFAULT, true);
>
> // SMALLINT (usually 2 bytes = 16bit)
> DEPARTMENT_ID = addColumn("DEPARTMENT_ID", DataType.INTEGER, SMALLINT, true);
>
> // BIGINT (usually 8 bytes = 64bit)
> DEPARTMENT_ID = addColumn("DEPARTMENT_ID", DataType.INTEGER, BIGINT, true);
>
> This is consistent over all drivers.
> However the exact interpretation of INT, SMALLINT an BIGINT is left to the database.
>
> That also solves EMPIREDB-105.
>
> Regards
> Rainer
>
>> from: francisdb@apache.org [mailto:francisdb@apache.org]
>> to: empire-db-commits@incubator.apache.org
>> re: svn commit: r1180840 - /incubator/empire-db/trunk/empire-
>> db/src/test/java/org/apache/empire/db/PreparedStatementTest.java
>>
>> Author: francisdb
>> Date: Mon Oct 10 09:27:18 2011
>> New Revision: 1180840
>>
>> URL: http://svn.apache.org/viewvc?rev=1180840&view=rev
>> Log:
>> This id field is now int instead of long (is this expected?)
>>
>> Modified:
>> incubator/empire-db/trunk/empire-
>> db/src/test/java/org/apache/empire/db/PreparedStatementTest.java
>>
>> Modified: incubator/empire-db/trunk/empire-
>> db/src/test/java/org/apache/empire/db/PreparedStatementTest.java
>> URL: http://svn.apache.org/viewvc/incubator/empire-db/trunk/empire-
>> db/src/test/java/org/apache/empire/db/PreparedStatementTest.java?rev=
>> 1180840&r1=1180839&r2=1180840&view=diff
>> ==========================================================
>> ====================
>> --- incubator/empire-db/trunk/empire-
>> db/src/test/java/org/apache/empire/db/PreparedStatementTest.java
>> (original)
>> +++ incubator/empire-db/trunk/empire-
>> db/src/test/java/org/apache/empire/db/PreparedStatementTest.java Mon
>> Oct 10 09:27:18 2011
>> @@ -54,7 +54,7 @@ public class PreparedStatementTest{
>> department.setValue(db.DEPARTMENT.BUSINESS_UNIT, "test");
>> department.update(conn);
>>
>> - long id = department.getInt(db.DEPARTMENT.ID);
>> + int id = department.getInt(db.DEPARTMENT.ID);
>> assertTrue("Department add failed", id > 0);
>>
>>
>>
>
>
--
http://www.somatik.be
Microsoft gives you windows, Linux gives you the whole house.