I think we should keep the scope of the JIRA. If you want to create a new
sample, with more advanced features (e.g OCC, etc), then I think we should
go with a new and more cool application using REST/AJAX sample app... (btw
there was couple discussions around this before, so I started something, but
never had the chance to get back to it (
https://svn.apache.org/repos/asf/incubator/tuscany/sandbox/lresende/ajaxDAS/
)
--
Luciano Resende
http://people.apache.org/~lresende
On 2/23/07, Amita Vadhavkar <[EMAIL PROTECTED]> wrote:
Hi Luciano,
Please see details below and let me know if we can scope for this, or
it is better to keep the current scope and just add the auto creation of
db.
In current sample we showcase only CRUD and that for only DEBRY.
We can have hooks using JIRA-863 to expand this. i.e. showcase
more features and use other DBs. We can go for Struts if that is more
convenient.
I am not sure how to do programmatic creation of DB2 database with a
check for its pre-existance.But there is a defined way in MySQL and Derby
as below:-
MySQL:property createDatabaseIfNotExist=true
Derby:create=true
The way to create the hooks can be something like below:-
DASWebSample.jsp
->decision control[Start CompanyWeb Derby Sample{param
dbName="derby"
testName="CRUD"}] -> DBSetup code -> Company CRUD examples
->decision control[Start CompanyWeb MySQL Sample{param
dbName="mysql" testName="CRUD"}]->DBSetup code->->Company CRUD examples
.....
->decision control[Start ConverterTest Derby{param
dbName="derby",
testName="converter"}->DBSetup code->->Converter test case
We can decide what all features to demo and can add some cases at later
point too.
DBSetup - can look at the param dbName and go for required db, tables,
data
creation. By default
if db is present , it will not be created and if table is present, it will
not be created. For table
data, we can either force refresh or refresh on demand.
By the above approach, we give flexibility to choose db vendor, test case,
data refresh and
programmer has flexibility to add new test cases.
So, by init params, I was trying to refer to a way to give some
scalability
to the current sample.
Regards, Amita
On 2/22/07, Luciano Resende <[EMAIL PROTECTED]> wrote:
>
> Hi Amita
>
> What I had in mind for Tuscany-863, was more around having a module
> responsible for creating the physical databases, populating the tables
> with
> default values and also being able to refresh these values to a original
> state. Then the sample applications would check the existence of these
> databases, and ask for creation, refresh or just use it if already
> available. This would allow us to remove the physical dbs we have in the
> source repository and would make sample installation much easier and
> automatically.
>
> I got little confused with your proposal, could you please elaborate
> little more ?
>
> --
> Luciano Resende
> http://people.apache.org/~lresende
>
> On 2/20/07, Amita Vadhavkar <[EMAIL PROTECTED]> wrote:
> >
> > Hi All,
> > Below is the link for the JIRA-
> > https://issues.apache.org/jira/browse/TUSCANY-863
> >
> > Using servlet init params, we can expand the current sample
(companyweb)
> > to
> > use
> > different DAS config xmls for demonstrating different DAS features.
> >
> > Any thoughts?
> >
> > Regards,
> > Amita
> >
>
