Mailing-List: contact jdo-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: jdo-dev@db.apache.org
Received-SPF: pass (asf.osuosl.org: local policy)
From: Andy Jefferson <andy@jpox.org>
To: jdo-dev@db.apache.org,
 JDO Expert Group <jdo-experts-ext@sun.com>
Subject: Re: RunRules for JDO TCK
Date: Sat, 31 Dec 2005 09:09:50 +0000
User-Agent: KMail/1.8.2
References: <4551421F-C192-443D-90B4-33E1C5ACA8F5@Sun.COM>
In-Reply-To: <4551421F-C192-443D-90B4-33E1C5ACA8F5@Sun.COM>
Organization: JPOX
MIME-Version: 1.0
Content-Type: text/plain;
  charset="iso-8859-6"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <200512310909.50797.andy@jpox.org>

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