objectbridge-developers

[OJB-developers] JUNIT failures & errors

[Thomas M. <tho...@ho...>]

Hi all,

I just checked in some minor fixes that cure most of the problems I 
mentioned in my last mail.

I set some log-messages in JdbcAccess from .error(...) to .debug(...).
This avoids all the internal stacktrace within the PB Junit tests.
This does not compromise stability as throwing of exceptions is not touched.

I found a minor issue in SqlUpdateStatement:
in appendSetClause(...) it uses appendColname from the baseclass 
SqlStatement.

This method is used to generate column names from field descriptors.
It uses FieldDescriptor.getFullColumnName() to build a column name.
This will include Schema and table name in a column name (i.e. a column 
"NAME" would be fullqualified as "MySchema.MyTable.NAME").

This may work in most situations, but it does not work for Update 
statements in Hsqldb (AFAIK DB2 and InstantDB also don't support this).

I refactored this code with the "template method" pattern, that allows 
subclasses to override the qualification behaviour.

Could this fix be problematic for other databases? Or could there be any 
cases where full-qualified names are needed within Update Statements?

Now we have the following JUnit results:
PersistenceBroker: 0 Failures, 0 Errors, 0 Stacktraces
SODA: 0 Failures, 0 Errors, 0 Stacktraces
ODMG: 0 Failures, 1 Error (resulting in some stacktracing)

The error is in test.ojb.odmg.OneToOneTest.testSave().

I hope to get this fixed soon.

cheers,

Thomas

Re: [OJB-developers] JUNIT failures & errors

[Jakob B. <jbr...@ho...>]

hi thomas,

> This may work in most situations, but it does not work for Update
> statements in Hsqldb (AFAIK DB2 and InstantDB also don't support this).

this is one of the main problems when dealing with multiple databases, i use
mysql as test database and there it works.
for some tests i also use ms-access but i never worked with hsqldb.
we need some kind of test platform, where we can run accesslayer-code
against _all_ supported databases.

jakob

----- Original Message -----
From: "Thomas Mahler" <tho...@ho...>
To: "ojb" <obj...@li...>
Sent: Sunday, June 02, 2002 4:22 PM
Subject: [OJB-developers] JUNIT failures & errors


> Hi all,
>
> I just checked in some minor fixes that cure most of the problems I
> mentioned in my last mail.
>
> I set some log-messages in JdbcAccess from .error(...) to .debug(...).
> This avoids all the internal stacktrace within the PB Junit tests.
> This does not compromise stability as throwing of exceptions is not
touched.
>
> I found a minor issue in SqlUpdateStatement:
> in appendSetClause(...) it uses appendColname from the baseclass
> SqlStatement.
>
> This method is used to generate column names from field descriptors.
> It uses FieldDescriptor.getFullColumnName() to build a column name.
> This will include Schema and table name in a column name (i.e. a column
> "NAME" would be fullqualified as "MySchema.MyTable.NAME").
>
> This may work in most situations, but it does not work for Update
> statements in Hsqldb (AFAIK DB2 and InstantDB also don't support this).
>
> I refactored this code with the "template method" pattern, that allows
> subclasses to override the qualification behaviour.
>
> Could this fix be problematic for other databases? Or could there be any
> cases where full-qualified names are needed within Update Statements?
>
> Now we have the following JUnit results:
> PersistenceBroker: 0 Failures, 0 Errors, 0 Stacktraces
> SODA: 0 Failures, 0 Errors, 0 Stacktraces
> ODMG: 0 Failures, 1 Error (resulting in some stacktracing)
>
> The error is in test.ojb.odmg.OneToOneTest.testSave().
>
> I hope to get this fixed soon.
>
> cheers,
>
> Thomas
>
>
> _______________________________________________________________
>
> Don't miss the 2002 Sprint PCS Application Developer's Conference
> August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm
>
> _______________________________________________
> Objectbridge-developers mailing list
> Obj...@li...
> https://lists.sourceforge.net/lists/listinfo/objectbridge-developers
>

Re: [OJB-developers] JUNIT failures & errors

[Matthew b. <mat...@ya...>]

 what subset of databases *should* be tested on to catch possible errors? HSQLDB seems to be easy to test on, MSSQL server covers sybase as well, and I know Oracle needs specific testing. Is it enough to test on those three
  



---------------------------------
Do You Yahoo!?
Yahoo! - Official partner of 2002 FIFA World Cup

Re: [OJB-developers] JUNIT failures & errors

[Jakob B. <jbr...@ho...>]

hi

what about mysql and msaccess, db2 ?
i think msaccess is on the list of supported databases, mysql is =
mentioned to run with little or no problem.
i agree about hsqldb, i've already set up the test-database and =
successfully ran all tests against it.=20
and i promise to use hsqldb as a test platform in the future...

jakob
  ----- Original Message -----=20
  From: Matthew baird=20
  To: Jakob Braeuchi ; Thomas Mahler ; ojb=20
  Sent: Sunday, June 02, 2002 9:15 PM
  Subject: Re: [OJB-developers] JUNIT failures & errors


  what subset of databases *should* be tested on to catch possible =
errors? HSQLDB seems to be easy to test on, MSSQL server covers sybase =
as well, and I know Oracle needs specific testing. Is it enough to test =
on those three=20

  =20





-------------------------------------------------------------------------=
-----
  Do You Yahoo!?
  Yahoo! - Official partner of 2002 FIFA World Cup

Re: [OJB-developers] JUNIT failures & errors

[Thomas M. <tho...@ho...>]

The real solution would be to test against all supported databases:

Hypersonic (HsqlDb)
MS_ACCESS
ORACLE
INSTANTDB
DB2
POSTGRESQL
MYSQL
INFORMIX
MSSQLSERVER2000

(There have also been contributions for Sybase compatibility that have 
not yet been incorporated into the distro yet. Its quite similar to 
Ms-SqlServer.)

cheers,

Thomas

Matthew baird wrote:

>   what subset of databases *should* be tested on to catch possible 
> errors? HSQLDB seems to be easy to test on, MSSQL server covers sybase 
> as well, and I know Oracle needs specific testing. Is it enough to test 
> on those three
> 
>  
> 
> 
> ------------------------------------------------------------------------
> *Do You Yahoo!?*
> Yahoo! <http://rd.yahoo.com/welcome/*http://fifaworldcup.yahoo.com> - 
> Official partner of 2002 FIFA World Cup

Re: [OJB-developers] JUNIT failures & errors

[Jakob B. <jbr...@ho...>]

hi,

can anybody _please_ tell me how to configure the build process for a db
different than hsqldb.
i modified the build.properties as follows:

...
HSQLDB=-HSQLDB
MS_ACCESS=+MS_ACCESS
...

but torque still uses hsqldb as displayed on the console:

...
[torque-sql] Resolver: used database.dtd from
org.apache.torque.engine.database.transform package

project-create-db-classpath:
     [echo]
      driver="org.hsqldb.jdbcDriver"
      url="jdbc:hsqldb:target/test/OJB"
      userid="sa"
      password=""

[torque-create-db] Using classpath
[torque-create-db] Generating to file
D:\Java\eclipse_0602\workspace\ojb-1-0\target\src\sql\create-db.sql
...

jakob

----- Original Message -----
From: "Thomas Mahler" <tho...@ho...>
To: "Matthew baird" <mat...@ya...>
Cc: "Jakob Braeuchi" <jbr...@ho...>; "ojb"
<obj...@li...>
Sent: Sunday, June 02, 2002 10:07 PM
Subject: Re: [OJB-developers] JUNIT failures & errors


> The real solution would be to test against all supported databases:
>
> Hypersonic (HsqlDb)
> MS_ACCESS
> ORACLE
> INSTANTDB
> DB2
> POSTGRESQL
> MYSQL
> INFORMIX
> MSSQLSERVER2000
>
> (There have also been contributions for Sybase compatibility that have
> not yet been incorporated into the distro yet. Its quite similar to
> Ms-SqlServer.)
>
> cheers,
>
> Thomas
>
> Matthew baird wrote:
>
> >   what subset of databases *should* be tested on to catch possible
> > errors? HSQLDB seems to be easy to test on, MSSQL server covers sybase
> > as well, and I know Oracle needs specific testing. Is it enough to test
> > on those three
> >
> >
> >
> >
> > ------------------------------------------------------------------------
> > *Do You Yahoo!?*
> > Yahoo! <http://rd.yahoo.com/welcome/*http://fifaworldcup.yahoo.com> -
> > Official partner of 2002 FIFA World Cup
>

Re: [OJB-developers] JUNIT failures & errors

[Thomas M. <tho...@ho...>]

Hi Jakob,

Jakob Braeuchi wrote:

> hi thomas,
> 
> 
>>This may work in most situations, but it does not work for Update
>>statements in Hsqldb (AFAIK DB2 and InstantDB also don't support this).
>>
> 
> this is one of the main problems when dealing with multiple databases, i use
> mysql as test database and there it works.


I agree!


> for some tests i also use ms-access but i never worked with hsqldb.
> we need some kind of test platform, where we can run accesslayer-code
> against _all_ supported databases.
> 


Yes, that would be the best solution.
But at my company I only have access to DB2, Oracle, MS-Access, and 
Hypersonic.

Licencing RDBMS is expensive ! It's also a know-how problem. I don't 
feel like learning about admistrating say Informix.

Maybe we can set up a kind of "distributed test farm" ?
Maybe it would be easier to just share the reponsibilities for testing 
against special platforms,
say:
Jakob : MySql
Thomas: HsqlDb, DB2
...
...

cheers,

thomas


> jakob
> 
> ----- Original Message -----
> From: "Thomas Mahler" <tho...@ho...>
> To: "ojb" <obj...@li...>
> Sent: Sunday, June 02, 2002 4:22 PM
> Subject: [OJB-developers] JUNIT failures & errors
> 
> 
> 
>>Hi all,
>>
>>I just checked in some minor fixes that cure most of the problems I
>>mentioned in my last mail.
>>
>>I set some log-messages in JdbcAccess from .error(...) to .debug(...).
>>This avoids all the internal stacktrace within the PB Junit tests.
>>This does not compromise stability as throwing of exceptions is not
>>
> touched.
> 
>>I found a minor issue in SqlUpdateStatement:
>>in appendSetClause(...) it uses appendColname from the baseclass
>>SqlStatement.
>>
>>This method is used to generate column names from field descriptors.
>>It uses FieldDescriptor.getFullColumnName() to build a column name.
>>This will include Schema and table name in a column name (i.e. a column
>>"NAME" would be fullqualified as "MySchema.MyTable.NAME").
>>
>>This may work in most situations, but it does not work for Update
>>statements in Hsqldb (AFAIK DB2 and InstantDB also don't support this).
>>
>>I refactored this code with the "template method" pattern, that allows
>>subclasses to override the qualification behaviour.
>>
>>Could this fix be problematic for other databases? Or could there be any
>>cases where full-qualified names are needed within Update Statements?
>>
>>Now we have the following JUnit results:
>>PersistenceBroker: 0 Failures, 0 Errors, 0 Stacktraces
>>SODA: 0 Failures, 0 Errors, 0 Stacktraces
>>ODMG: 0 Failures, 1 Error (resulting in some stacktracing)
>>
>>The error is in test.ojb.odmg.OneToOneTest.testSave().
>>
>>I hope to get this fixed soon.
>>
>>cheers,
>>
>>Thomas
>>
>>
>>_______________________________________________________________
>>
>>Don't miss the 2002 Sprint PCS Application Developer's Conference
>>August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm
>>
>>_______________________________________________
>>Objectbridge-developers mailing list
>>Obj...@li...
>>https://lists.sourceforge.net/lists/listinfo/objectbridge-developers
>>
>>
> 
> _______________________________________________________________
> 
> Don't miss the 2002 Sprint PCS Application Developer's Conference
> August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm
> 
> _______________________________________________
> Objectbridge-developers mailing list
> Obj...@li...
> https://lists.sourceforge.net/lists/listinfo/objectbridge-developers
> 
> 
> 
>