Yep, still want to test your changes on some other databases first On Mon, Oct 10, 2011 at 7:08 PM, Rainer Döbele <[email protected]> wrote: > 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:[email protected]] >> to: [email protected] >> 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 <[email protected]> >> 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:[email protected]] >> >> to: [email protected] >> >> Re: Failure of PreparedStatementTest >> >> >> >> On Mon, Oct 10, 2011 at 4:51 PM, Rainer Döbele <[email protected]> >> >> 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: [email protected] [mailto:[email protected]] >> >> >> to: [email protected] >> >> >> 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. >
-- http://www.somatik.be Microsoft gives you windows, Linux gives you the whole house.
