empire-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rainer Döbele <doeb...@esteam.de>
Subject re: Failure of PreparedStatementTest
Date Mon, 10 Oct 2011 17:08:29 GMT
Hi Francis,

thanks for resolving this and I apologize that I have not done it myself.
But I feel a little ill today and I just needed a rest after my email.

How about a new release soon?
I think we should give it another few days for people to check (including me) but then I think
we will be ready for it.

Best regards
Rainer

> from: Francis De Brabandere [mailto:francisdb@gmail.com]
> to: empire-db-dev@incubator.apache.org
> re: Re: Failure of PreparedStatementTest
> 
> I agree, I'll make the change unless you plan to do it.
> 
> On Mon, Oct 10, 2011 at 5:15 PM, Rainer Döbele <doebele@esteam.de>
> wrote:
> >
> > Ok looks like a comparision of an int and a long is always false, no
> matter whether the underlying value is the same or not.
> > From a technical point of view this is understandable but not from a
> logical point of view.
> >
> > Still, I think the problem here is out test code that uses an int on
> one side and an object on the other:
> >
> >        int id = department.getInt(db.DEPARTMENT.ID);
> >        ...
> >        assertEquals(id, r.getValue(DEP.ID));
> >
> > Hence we should eighter use int, long or objects on both sides.
> >
> > Either this:
> >
> >        Object id = department.getValue(db.DEPARTMENT.ID);
> >        ...
> >        assertEquals(id, r.getValue(DEP.ID));
> >
> > or something like this:
> >
> >        int id = department.getValue(db.DEPARTMENT.ID);
> >        ...
> >        assertEquals(id, r.getInt(DEP.ID));
> >
> > (int or long doesn't matter)
> >
> > Regards
> > Rainer
> >
> >> from: Francis De Brabandere [mailto:francisdb@gmail.com]
> >> to: empire-db-dev@incubator.apache.org
> >> Re: Failure of PreparedStatementTest
> >>
> >> On Mon, Oct 10, 2011 at 4:51 PM, Rainer Döbele <doebele@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.
> >
> 
> 
> 
> --
> http://www.somatik.be
> Microsoft gives you windows, Linux gives you the whole house.

Mime
View raw message