Return-Path: 
 <cocoon-dev-return-38227-apmail-xml-cocoon-dev-archive=xml.apache.org@xml.apache.org>
Delivered-To: apmail-xml-cocoon-dev-archive@xml.apache.org
Received: (qmail 84778 invoked by uid 500); 12 Mar 2003 13:46:00 -0000
Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm
Precedence: bulk
list-help: <mailto:cocoon-dev-help@xml.apache.org>
list-unsubscribe: <mailto:cocoon-dev-unsubscribe@xml.apache.org>
list-post: <mailto:cocoon-dev@xml.apache.org>
Reply-To: cocoon-dev@xml.apache.org
Delivered-To: mailing list cocoon-dev@xml.apache.org
Received: (qmail 84763 invoked from network); 12 Mar 2003 13:45:59 -0000
Received: from unknown (HELO mail.dff.local) (62.159.19.130)
  by daedalus.apache.org with SMTP; 12 Mar 2003 13:45:59 -0000
Received: from altair.dff.local ([172.16.2.8] helo=dff.st)
	by mail.dff.local with esmtp (Exim 3.35 #1)
	id 18t6YS-0000Ku-00
	for cocoon-dev@xml.apache.org; Wed, 12 Mar 2003 14:46:00 +0100
Message-ID: <3E6F3A52.3010905@dff.st>
Date: Wed, 12 Mar 2003 14:46:58 +0100
From: Torsten Curdt <tcurdt@dff.st>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US;
 rv:1.3b) Gecko/20030210
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: cocoon-dev@xml.apache.org
Subject: Re: esql samples
References: <3E6E1DE7.7050507@dff.st> <3E6E0582.3020704@apache.org>
 <56D570AA-53BD-11D7-B62B-0030653FE818@apache.org>
 <3E6E0582.3020704@apache.org>
 <5.2.0.9.0.20030311112214.00b04c28@leverageweb.com> <3E6E1DE7.7050507@dff.st>
 <5.2.0.9.0.20030312080128.02d506c8@leverageweb.com>
In-Reply-To: <5.2.0.9.0.20030312080128.02d506c8@leverageweb.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N

<snip/>

> That's why I wouldn't give up too easily on making the db setup work
> from a normal sql script. Currently we have the .sql out there, but
> I'm not sure it's up to date (though it looks like it), and if it's
> not used, it's certainly in danger of getting out of date at some
> point.

But the .script file *is* actually a simple .sql script.

> Now that the samples are at least working again, how about considering
> some options for actually creating the samples "schema" from the .sql?

But we could split the cocoondb.script file into

cocoondb.setup + cocoondb.sql --ant--> cocoondb.script

So the schema is pretty much the cocoondb.sql file that could also be 
copied into the samples. Or do you mean a real "schema"?

<snip/>

 > Users could provide the db
> connection name, which would let them use hsql by default, or any other 
> db they've already set up.

Sorry, I cannot find a good reason on reading the samples entries from 
an already setup db ;) Why would you want to do this?
--
Torsten