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 <[EMAIL PROTECTED]>: > 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:[EMAIL PROTECTED] > > > > P.S. A good JDO? O, Gasp! > > > > > > > -- > Michael Bouschen [EMAIL PROTECTED] Engineering GmbH > mailto:[EMAIL PROTECTED] http://www.tech.spree.de/ > Tel.:++49/30/235 520-33 Buelowstr. 66 > Fax.:++49/30/2175 2012 D-10783 Berlin >
