db-jdo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Bouschen <mbo.t...@spree.de>
Subject Re: RunRules for JDO TCK
Date Fri, 06 Jan 2006 14:26:14 GMT
Hi Craig,

> Javadogs,
> 
> I'm inclined to agree with Andy that the schema and orm files for each 
> of the databases we know of should be standard and specified as part of 
> the TCK.

I agree.

> 
> There is nothing in the TCK tests that should be different in the orm 
> files from one database to another. There are differences in the schema 
> based on column data types, and these differences can be captured in 
> database-specific .sql files.

AFAIK there is nothing in the current orm files that needs to change for 
a different database or that requires vendor specific extensions.

> 
> The only thing we lack is broader testing on different databases. But 
> for now, I'll be happy to require that the orm files be identical among 
> different databases, and even happier if we can get some folks to create 
> the xxx.sql files for databases other than derby.

I'm wondering what needs to be done to test a JDO implementation against 
a database <db> different from derby:
- Copy all the orm files to package-<db>.orm. This is necessary because 
the orm files include the database in its name, e.g. package-derby.orm.
- Create a new subdirectory <db> under trunk/tck20/test/sql and provide 
the corresponding sql files schema*.sql.

More?

Regards Michael


> 
> Craig
> 
> On Dec 31, 2005, at 1:09 AM, Andy Jefferson wrote:
> 
>> Hi Craig,
>>
>>> Attached please find the first draft of the TCK run rules for JDO
>>> 2.0. Please comment.
>>
>>
>> Why is the "sql" modifiable "to suit the JDO implementation" ?
>> Why is the "orm" modifiable "to suit the JDO implementation" ?
>>
>> Surely the ORM defines the underlying schema, and so the ORM files 
>> provided 
>> with the TCK are totally compatible with the schema provided with the 
>> TCK. 
>> That is the premise we have been using with JPOX whilst developing the 
>> TCK. 
>> Why is it different for other implementations?
>> Can we have some examples of why it would be necessary ?
>> Are we talking about JDO implementations that don't support Apache 
>> Derby ? In 
>> that case would it not be better to have any other RDBMS files 
>> generated be 
>> fed back to the TCK project and then have them under central control? We 
>> can't have one JDO implementation hand crafting its own SQL files and ORM 
>> files and saying that it is "compatible" when the ORM they have 
>> generated may 
>> be incorrect with respect to the spec and the schema it should equate 
>> to. e.g 
>>
>>
>> Thanks
>> -- 
>> Andy
> 
> 
> Craig Russell
> 
> Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
> 
> 408 276-5638 mailto:Craig.Russell@sun.com
> 
> P.S. A good JDO? O, Gasp!
> 
> 


-- 
Michael Bouschen		Tech@Spree Engineering GmbH
mailto:mbo.tech@spree.de	http://www.tech.spree.de/
Tel.:++49/30/235 520-33		Buelowstr. 66			
Fax.:++49/30/2175 2012		D-10783 Berlin			

Mime
View raw message