You are viewing a plain text version of this content. The canonical link for it is here.
Posted to jdo-dev@db.apache.org by Craig L Russell <Cr...@Sun.COM> on 2006/01/06 03:46:45 UTC
Re: RunRules for JDO TCK
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.
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.
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.
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!
Re: RunRules for JDO TCK
Posted by er...@jpox.org.
The installSchema goal is only handling derby database. Should't exist a generic
implementation that connects to any database using a jdbc driver, reads and
fires sql scripts to database B, C or D?
Quoting Michael Bouschen <mb...@spree.de>:
> 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
>
Re: RunRules for JDO TCK
Posted by Michael Bouschen <mb...@spree.de>.
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