You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tuscany.apache.org by Luciano Resende <lu...@gmail.com> on 2007/04/10 17:25:21 UTC
[DAS] Automatically Creating sample canned databases
Hi Amita
Today, we have couple of DAS sample applications (companyWeb, customer,
das-service) and they mostly rely on same set of databases table and the
solution we have today is to have the actual derby canned db checked in and
copied when it need to be used. This per si is a problem, but also, if you
want to use the sample with another db (e.g MySQL) you would have to create
the canned DB yourself. There is also a small issue when performing
automated integration testings using htmlUnit, that we need a way to refresh
the data to it's initial status, to allow running the test again without
having to re-copy the canned databases.
The idea behind Tuscany-863 is to try solve these issues mentioned above,
so the solution should be something that we could share between all the
sample applications, maybe a module that would create a jar to handle this
canned db, and the applications using the canned DBs would include the jar
to handle creation population and refreshing the canned DB data.
The patch you produced for Tuscany-863 is embedded on the companyWeb
sample, so I think it would be better to investigate the possibility to move
it to it's own module. I'm also open to hear other possible solutions, or
approaches, that would address the scenarios mentioned above.
Thoughts ?
--
Luciano Resende
http://people.apache.org/~lresende
Re: [DAS] Automatically Creating sample canned databases
Posted by Kevin Williams <ke...@qwest.net>.
There is also the framework we currently have in place that preloads the
database for our unit tests. It is a bit clumsy in places like creating
multiple tables with relationships but it is working.
--Kevin
Luciano Resende wrote:
> Looking into the same direction as kevin, and trying to find existing
> utility libraries that would help, looks like Apache DB have one that can
> help with the database structure [1], and could be used
> programatically [2],
> and once the physical db is available, we could use DAS to populate it ?
>
> I'll let you guys know if I find anything else available, if anybody is
> familiar with any other utilities please let us know as well.
>
> [1] - http://db.apache.org/ddlutils/
> [2] - http://db.apache.org/ddlutils/api-usage.html
>
>
>
> On 4/16/07, Luciano Resende <lu...@gmail.com> wrote:
>
>>
>> Well, DBUnit has a LGPL license [1], and I think this is not ASF
>> friendly.
>> I'd avoid looking further into this utility.
>>
>> [1] - http://dbunit.svn.sourceforge.net/svnroot/dbunit/trunk/LICENSE.txt
>>
>> On 4/16/07, Kevin Williams <ke...@qwest.net> wrote:
>> >
>> > I have not had a chance to investigate but there is OS utility named
>> > DBUnit (http://www.dbunit.org/) that is designed to create, preload
>> and
>> > refresh databases for use in testing.
>> >
>> >
>> > Amita Vadhavkar wrote:
>> >
>> > > Hi Luciano,
>> > >
>> > > Yes, I am making a util jar for that. Please check all the below
>> > > details and
>> > > let me know
>> > > yout suggestions.
>> > >
>> > > Trying to reuse part of DAS config.xsd's (ConnectionInfo portion
>> ) to
>> > > supply
>> > > the connection params and adding a new element to xsd to list
>> database
>> > > table
>> > > names that need to be created. This way different samples can
>> restrict
>> >
>> > > the
>> > > number of tables created based on their need.
>> > >
>> > > Also, making methods to do force/needBased refresh of tables and
>> data.
>> > > i.e.
>> > > control table
>> > > creation and data refresh.
>> > >
>> > > We can use same jar in web samples and standalone samples.
>> > >
>> > > The methods exposed to the clients of this jar will be
>> dbInit.createDB
>> > > (DBConfigFileName);
>> > > dbInit.createSchema(boolean) - for force/need base table creation,
>> > > dbInit.createData(boolean)-
>> > > for force/need base data refresh.
>> > >
>> > > Can be more granular - like which table to create/data to refresh -
>> > > but then the whole referntial integrity will need to be taken
>> care, So
>> > to
>> > > keep it simple - at present - its all tables/none , not selective.
>> > >
>> > > I am assuming that the table structure is internal knowledge of this
>> > > util,
>> > > i.e. not allowing externally defining table structures etc. (sim. to
>> > > what we
>> > > have at present in rdb). Only flexibility is - which are the tables
>> > > required
>> > > by the current client. Will that suffice for the current need? We
>> can
>> > add
>> > > that later if it is essential for some apps/samples.
>> > >
>> > > Pasting here the structure of DBConfig.xsd. See if this will meet
>> the
>> > > requirements. Can add database vendor name to support different
>> > databases
>> > > like Derby, DB2, MySQL etc.
>> > > One question here is -
>> > > For DB2 database creation - from java, how to do this? There are
>> ways
>> > for
>> > > this in MySQL and Derby but could not find for DB2, any pointers?
>> > >
>> > > Below is the xsd.
>> > >
>> >
>> _________________________________________________________________________________
>>
>> >
>> > >
>> > > <?xml version="1.0" encoding="UTF-8"?>
>> > > <!--
>> > > Licensed to the Apache Software Foundation (ASF) under one
>> > > or more contributor license agreements. See the NOTICE file
>> > > distributed with this work for additional information
>> > > regarding copyright ownership. The ASF licenses this file
>> > > to you under the Apache License, Version 2.0 (the
>> > > "License"); you may not use this file except in compliance
>> > > with the License. You may obtain a copy of the License at
>> > >
>> > > http://www.apache.org/licenses/LICENSE-2.0
>> > >
>> > > Unless required by applicable law or agreed to in writing,
>> > > software distributed under the License is distributed on an
>> > > "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
>> > > KIND, either express or implied. See the License for the
>> > > specific language governing permissions and limitations
>> > > under the License.
>> > > -->
>> > > <xsd:schema
>> > > xmlns:DBConfig="http:///org.apache.tuscany.das.rdb/DBConfig.xsd"
>> > > xmlns:xsd=" http://www.w3.org/2001/XMLSchema"
>> > > elementFormDefault="qualified"
>> > > targetNamespace=" http:///org.apache.tuscany.das.rdb/DBConfig.xsd">
>> > >
>> > > <xsd:element name="DBConfig" type="DBConfig:DBConfig"/>
>> > >
>> > > <xsd:complexType name="DBConfig">
>> > > <xsd:sequence>
>> > > <xsd:element maxOccurs="1" minOccurs="1"
>> name="ConnectionInfo"
>> > > type="DBConfig:ConnectionInfo"/>
>> > > <xsd:element maxOccurs="1" minOccurs="1" name="TableList"
>> > > type="DBConfig:TableList"/>
>> > > </xsd:sequence>
>> > > <xsd:attribute name="forceRecreate" type="xsd:boolean"/>
>> > > <xsd:attribute name="forceDataRefresh" type="xsd:boolean"/>
>> > > </xsd:complexType>
>> > >
>> > > <xsd:complexType name="ConnectionProperties">
>> > > <xsd:attribute name="driverClass" type="xsd:string"/>
>> > > <xsd:attribute name="databaseURL" type="xsd:string"/>
>> > > <xsd:attribute default="" name="userName" type="xsd:string"/>
>> > > <xsd:attribute default="" name="password" type="xsd:string"/>
>> > > <xsd:attribute default="0" name="loginTimeout" type="xsd:int"/>
>> > > </xsd:complexType>
>> > >
>> > > <xsd:complexType name="ConnectionInfo">
>> > > <xsd:sequence>
>> > > <xsd:element maxOccurs="1" minOccurs="0"
>> > > name="ConnectionProperties"
>> > > type="DBConfig:ConnectionProperties"/>
>> > > </xsd:sequence>
>> > > <xsd:attribute name="dataSource" type="xsd:string"/>
>> > > </xsd:complexType>
>> > >
>> > > <xsd:complexType name="TableList">
>> > > <xsd:sequence>
>> > > <xsd:element maxOccurs="unbounded" minOccurs="0"
>> > name="TableName"
>> > > type="xsd:string"/>
>> > > </xsd:sequence>
>> > > </xsd:complexType>
>> > > </xsd:schema>
>> > >
>> > >
>> > > On 4/10/07, Luciano Resende <lu...@gmail.com> wrote:
>> > >
>> > >>
>> > >> Hi Amita
>> > >>
>> > >> Today, we have couple of DAS sample applications (companyWeb,
>> > >> customer,
>> > >> das-service) and they mostly rely on same set of databases table
>> and
>> > the
>> > >> solution we have today is to have the actual derby canned db
>> checked
>> > in
>> > >> and
>> > >> copied when it need to be used. This per si is a problem, but also,
>> > >> if you
>> > >> want to use the sample with another db (e.g MySQL) you would
>> have to
>> > >> create
>> > >> the canned DB yourself. There is also a small issue when performing
>> > >> automated integration testings using htmlUnit, that we need a
>> way to
>> > >> refresh
>> > >> the data to it's initial status, to allow running the test again
>> > without
>> > >> having to re-copy the canned databases.
>> > >>
>> > >> The idea behind Tuscany-863 is to try solve these issues
>> mentioned
>> > >> above,
>> > >> so the solution should be something that we could share between all
>> > the
>> > >> sample applications, maybe a module that would create a jar to
>> handle
>> >
>> > >> this
>> > >> canned db, and the applications using the canned DBs would include
>> > >> the jar
>> > >> to handle creation population and refreshing the canned DB data.
>> > >>
>> > >> The patch you produced for Tuscany-863 is embedded on the
>> > companyWeb
>> > >> sample, so I think it would be better to investigate the
>> possibility
>> > to
>> > >> move
>> > >> it to it's own module. I'm also open to hear other possible
>> > >> solutions, or
>> > >> approaches, that would address the scenarios mentioned above.
>> > >>
>> > >> Thoughts ?
>> > >>
>> > >> --
>> > >> Luciano Resende
>> > >>
>> http://people.apache.org/~lresende<http://people.apache.org/%7Elresende>
>> > >>
>> > >
>> >
>> >
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
>> > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>> >
>> >
>>
>>
>> --
>> Luciano Resende
>> http://people.apache.org/~lresende
>> <http://people.apache.org/%7Elresende>
>>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: [DAS] Automatically Creating sample canned databases
Posted by Luciano Resende <lu...@gmail.com>.
Looking into the same direction as kevin, and trying to find existing
utility libraries that would help, looks like Apache DB have one that can
help with the database structure [1], and could be used programatically [2],
and once the physical db is available, we could use DAS to populate it ?
I'll let you guys know if I find anything else available, if anybody is
familiar with any other utilities please let us know as well.
[1] - http://db.apache.org/ddlutils/
[2] - http://db.apache.org/ddlutils/api-usage.html
On 4/16/07, Luciano Resende <lu...@gmail.com> wrote:
>
> Well, DBUnit has a LGPL license [1], and I think this is not ASF friendly.
> I'd avoid looking further into this utility.
>
> [1] - http://dbunit.svn.sourceforge.net/svnroot/dbunit/trunk/LICENSE.txt
>
> On 4/16/07, Kevin Williams <ke...@qwest.net> wrote:
> >
> > I have not had a chance to investigate but there is OS utility named
> > DBUnit (http://www.dbunit.org/) that is designed to create, preload and
> > refresh databases for use in testing.
> >
> >
> > Amita Vadhavkar wrote:
> >
> > > Hi Luciano,
> > >
> > > Yes, I am making a util jar for that. Please check all the below
> > > details and
> > > let me know
> > > yout suggestions.
> > >
> > > Trying to reuse part of DAS config.xsd's (ConnectionInfo portion ) to
> > > supply
> > > the connection params and adding a new element to xsd to list database
> > > table
> > > names that need to be created. This way different samples can restrict
> >
> > > the
> > > number of tables created based on their need.
> > >
> > > Also, making methods to do force/needBased refresh of tables and data.
> > > i.e.
> > > control table
> > > creation and data refresh.
> > >
> > > We can use same jar in web samples and standalone samples.
> > >
> > > The methods exposed to the clients of this jar will be dbInit.createDB
> > > (DBConfigFileName);
> > > dbInit.createSchema(boolean) - for force/need base table creation,
> > > dbInit.createData(boolean)-
> > > for force/need base data refresh.
> > >
> > > Can be more granular - like which table to create/data to refresh -
> > > but then the whole referntial integrity will need to be taken care, So
> > to
> > > keep it simple - at present - its all tables/none , not selective.
> > >
> > > I am assuming that the table structure is internal knowledge of this
> > > util,
> > > i.e. not allowing externally defining table structures etc. (sim. to
> > > what we
> > > have at present in rdb). Only flexibility is - which are the tables
> > > required
> > > by the current client. Will that suffice for the current need? We can
> > add
> > > that later if it is essential for some apps/samples.
> > >
> > > Pasting here the structure of DBConfig.xsd. See if this will meet the
> > > requirements. Can add database vendor name to support different
> > databases
> > > like Derby, DB2, MySQL etc.
> > > One question here is -
> > > For DB2 database creation - from java, how to do this? There are ways
> > for
> > > this in MySQL and Derby but could not find for DB2, any pointers?
> > >
> > > Below is the xsd.
> > >
> > _________________________________________________________________________________
> >
> > >
> > > <?xml version="1.0" encoding="UTF-8"?>
> > > <!--
> > > Licensed to the Apache Software Foundation (ASF) under one
> > > or more contributor license agreements. See the NOTICE file
> > > distributed with this work for additional information
> > > regarding copyright ownership. The ASF licenses this file
> > > to you under the Apache License, Version 2.0 (the
> > > "License"); you may not use this file except in compliance
> > > with the License. You may obtain a copy of the License at
> > >
> > > http://www.apache.org/licenses/LICENSE-2.0
> > >
> > > Unless required by applicable law or agreed to in writing,
> > > software distributed under the License is distributed on an
> > > "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
> > > KIND, either express or implied. See the License for the
> > > specific language governing permissions and limitations
> > > under the License.
> > > -->
> > > <xsd:schema
> > > xmlns:DBConfig="http:///org.apache.tuscany.das.rdb/DBConfig.xsd"
> > > xmlns:xsd=" http://www.w3.org/2001/XMLSchema"
> > > elementFormDefault="qualified"
> > > targetNamespace=" http:///org.apache.tuscany.das.rdb/DBConfig.xsd">
> > >
> > > <xsd:element name="DBConfig" type="DBConfig:DBConfig"/>
> > >
> > > <xsd:complexType name="DBConfig">
> > > <xsd:sequence>
> > > <xsd:element maxOccurs="1" minOccurs="1" name="ConnectionInfo"
> > > type="DBConfig:ConnectionInfo"/>
> > > <xsd:element maxOccurs="1" minOccurs="1" name="TableList"
> > > type="DBConfig:TableList"/>
> > > </xsd:sequence>
> > > <xsd:attribute name="forceRecreate" type="xsd:boolean"/>
> > > <xsd:attribute name="forceDataRefresh" type="xsd:boolean"/>
> > > </xsd:complexType>
> > >
> > > <xsd:complexType name="ConnectionProperties">
> > > <xsd:attribute name="driverClass" type="xsd:string"/>
> > > <xsd:attribute name="databaseURL" type="xsd:string"/>
> > > <xsd:attribute default="" name="userName" type="xsd:string"/>
> > > <xsd:attribute default="" name="password" type="xsd:string"/>
> > > <xsd:attribute default="0" name="loginTimeout" type="xsd:int"/>
> > > </xsd:complexType>
> > >
> > > <xsd:complexType name="ConnectionInfo">
> > > <xsd:sequence>
> > > <xsd:element maxOccurs="1" minOccurs="0"
> > > name="ConnectionProperties"
> > > type="DBConfig:ConnectionProperties"/>
> > > </xsd:sequence>
> > > <xsd:attribute name="dataSource" type="xsd:string"/>
> > > </xsd:complexType>
> > >
> > > <xsd:complexType name="TableList">
> > > <xsd:sequence>
> > > <xsd:element maxOccurs="unbounded" minOccurs="0"
> > name="TableName"
> > > type="xsd:string"/>
> > > </xsd:sequence>
> > > </xsd:complexType>
> > > </xsd:schema>
> > >
> > >
> > > On 4/10/07, Luciano Resende <lu...@gmail.com> wrote:
> > >
> > >>
> > >> Hi Amita
> > >>
> > >> Today, we have couple of DAS sample applications (companyWeb,
> > >> customer,
> > >> das-service) and they mostly rely on same set of databases table and
> > the
> > >> solution we have today is to have the actual derby canned db checked
> > in
> > >> and
> > >> copied when it need to be used. This per si is a problem, but also,
> > >> if you
> > >> want to use the sample with another db (e.g MySQL) you would have to
> > >> create
> > >> the canned DB yourself. There is also a small issue when performing
> > >> automated integration testings using htmlUnit, that we need a way to
> > >> refresh
> > >> the data to it's initial status, to allow running the test again
> > without
> > >> having to re-copy the canned databases.
> > >>
> > >> The idea behind Tuscany-863 is to try solve these issues mentioned
> > >> above,
> > >> so the solution should be something that we could share between all
> > the
> > >> sample applications, maybe a module that would create a jar to handle
> >
> > >> this
> > >> canned db, and the applications using the canned DBs would include
> > >> the jar
> > >> to handle creation population and refreshing the canned DB data.
> > >>
> > >> The patch you produced for Tuscany-863 is embedded on the
> > companyWeb
> > >> sample, so I think it would be better to investigate the possibility
> > to
> > >> move
> > >> it to it's own module. I'm also open to hear other possible
> > >> solutions, or
> > >> approaches, that would address the scenarios mentioned above.
> > >>
> > >> Thoughts ?
> > >>
> > >> --
> > >> Luciano Resende
> > >> http://people.apache.org/~lresende<http://people.apache.org/%7Elresende>
> > >>
> > >
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> >
> >
>
>
> --
> Luciano Resende
> http://people.apache.org/~lresende <http://people.apache.org/%7Elresende>
>
--
Luciano Resende
http://people.apache.org/~lresende
Re: [DAS] Automatically Creating sample canned databases
Posted by Luciano Resende <lu...@gmail.com>.
Well, DBUnit has a LGPL license [1], and I think this is not ASF friendly.
I'd avoid looking further into this utility.
[1] - http://dbunit.svn.sourceforge.net/svnroot/dbunit/trunk/LICENSE.txt
On 4/16/07, Kevin Williams <ke...@qwest.net> wrote:
>
> I have not had a chance to investigate but there is OS utility named
> DBUnit (http://www.dbunit.org/) that is designed to create, preload and
> refresh databases for use in testing.
>
>
> Amita Vadhavkar wrote:
>
> > Hi Luciano,
> >
> > Yes, I am making a util jar for that. Please check all the below
> > details and
> > let me know
> > yout suggestions.
> >
> > Trying to reuse part of DAS config.xsd's (ConnectionInfo portion ) to
> > supply
> > the connection params and adding a new element to xsd to list database
> > table
> > names that need to be created. This way different samples can restrict
> > the
> > number of tables created based on their need.
> >
> > Also, making methods to do force/needBased refresh of tables and data.
> > i.e.
> > control table
> > creation and data refresh.
> >
> > We can use same jar in web samples and standalone samples.
> >
> > The methods exposed to the clients of this jar will be dbInit.createDB
> > (DBConfigFileName);
> > dbInit.createSchema(boolean) - for force/need base table creation,
> > dbInit.createData(boolean)-
> > for force/need base data refresh.
> >
> > Can be more granular - like which table to create/data to refresh -
> > but then the whole referntial integrity will need to be taken care, So
> to
> > keep it simple - at present - its all tables/none , not selective.
> >
> > I am assuming that the table structure is internal knowledge of this
> > util,
> > i.e. not allowing externally defining table structures etc. (sim. to
> > what we
> > have at present in rdb). Only flexibility is - which are the tables
> > required
> > by the current client. Will that suffice for the current need? We can
> add
> > that later if it is essential for some apps/samples.
> >
> > Pasting here the structure of DBConfig.xsd. See if this will meet the
> > requirements. Can add database vendor name to support different
> databases
> > like Derby, DB2, MySQL etc.
> > One question here is -
> > For DB2 database creation - from java, how to do this? There are ways
> for
> > this in MySQL and Derby but could not find for DB2, any pointers?
> >
> > Below is the xsd.
> >
> _________________________________________________________________________________
> >
> > <?xml version="1.0" encoding="UTF-8"?>
> > <!--
> > Licensed to the Apache Software Foundation (ASF) under one
> > or more contributor license agreements. See the NOTICE file
> > distributed with this work for additional information
> > regarding copyright ownership. The ASF licenses this file
> > to you under the Apache License, Version 2.0 (the
> > "License"); you may not use this file except in compliance
> > with the License. You may obtain a copy of the License at
> >
> > http://www.apache.org/licenses/LICENSE-2.0
> >
> > Unless required by applicable law or agreed to in writing,
> > software distributed under the License is distributed on an
> > "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
> > KIND, either express or implied. See the License for the
> > specific language governing permissions and limitations
> > under the License.
> > -->
> > <xsd:schema
> > xmlns:DBConfig="http:///org.apache.tuscany.das.rdb/DBConfig.xsd"
> > xmlns:xsd="http://www.w3.org/2001/XMLSchema"
> > elementFormDefault="qualified"
> > targetNamespace="http:///org.apache.tuscany.das.rdb/DBConfig.xsd">
> >
> > <xsd:element name="DBConfig" type="DBConfig:DBConfig"/>
> >
> > <xsd:complexType name="DBConfig">
> > <xsd:sequence>
> > <xsd:element maxOccurs="1" minOccurs="1" name="ConnectionInfo"
> > type="DBConfig:ConnectionInfo"/>
> > <xsd:element maxOccurs="1" minOccurs="1" name="TableList"
> > type="DBConfig:TableList"/>
> > </xsd:sequence>
> > <xsd:attribute name="forceRecreate" type="xsd:boolean"/>
> > <xsd:attribute name="forceDataRefresh" type="xsd:boolean"/>
> > </xsd:complexType>
> >
> > <xsd:complexType name="ConnectionProperties">
> > <xsd:attribute name="driverClass" type="xsd:string"/>
> > <xsd:attribute name="databaseURL" type="xsd:string"/>
> > <xsd:attribute default="" name="userName" type="xsd:string"/>
> > <xsd:attribute default="" name="password" type="xsd:string"/>
> > <xsd:attribute default="0" name="loginTimeout" type="xsd:int"/>
> > </xsd:complexType>
> >
> > <xsd:complexType name="ConnectionInfo">
> > <xsd:sequence>
> > <xsd:element maxOccurs="1" minOccurs="0"
> > name="ConnectionProperties"
> > type="DBConfig:ConnectionProperties"/>
> > </xsd:sequence>
> > <xsd:attribute name="dataSource" type="xsd:string"/>
> > </xsd:complexType>
> >
> > <xsd:complexType name="TableList">
> > <xsd:sequence>
> > <xsd:element maxOccurs="unbounded" minOccurs="0" name="TableName"
> > type="xsd:string"/>
> > </xsd:sequence>
> > </xsd:complexType>
> > </xsd:schema>
> >
> >
> > On 4/10/07, Luciano Resende <lu...@gmail.com> wrote:
> >
> >>
> >> Hi Amita
> >>
> >> Today, we have couple of DAS sample applications (companyWeb,
> >> customer,
> >> das-service) and they mostly rely on same set of databases table and
> the
> >> solution we have today is to have the actual derby canned db checked in
> >> and
> >> copied when it need to be used. This per si is a problem, but also,
> >> if you
> >> want to use the sample with another db (e.g MySQL) you would have to
> >> create
> >> the canned DB yourself. There is also a small issue when performing
> >> automated integration testings using htmlUnit, that we need a way to
> >> refresh
> >> the data to it's initial status, to allow running the test again
> without
> >> having to re-copy the canned databases.
> >>
> >> The idea behind Tuscany-863 is to try solve these issues mentioned
> >> above,
> >> so the solution should be something that we could share between all the
> >> sample applications, maybe a module that would create a jar to handle
> >> this
> >> canned db, and the applications using the canned DBs would include
> >> the jar
> >> to handle creation population and refreshing the canned DB data.
> >>
> >> The patch you produced for Tuscany-863 is embedded on the companyWeb
> >> sample, so I think it would be better to investigate the possibility to
> >> move
> >> it to it's own module. I'm also open to hear other possible
> >> solutions, or
> >> approaches, that would address the scenarios mentioned above.
> >>
> >> Thoughts ?
> >>
> >> --
> >> Luciano Resende
> >> http://people.apache.org/~lresende
> >>
> >
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
--
Luciano Resende
http://people.apache.org/~lresende
Re: [DAS] Automatically Creating sample canned databases
Posted by Kevin Williams <ke...@qwest.net>.
I have not had a chance to investigate but there is OS utility named
DBUnit (http://www.dbunit.org/) that is designed to create, preload and
refresh databases for use in testing.
Amita Vadhavkar wrote:
> Hi Luciano,
>
> Yes, I am making a util jar for that. Please check all the below
> details and
> let me know
> yout suggestions.
>
> Trying to reuse part of DAS config.xsd's (ConnectionInfo portion ) to
> supply
> the connection params and adding a new element to xsd to list database
> table
> names that need to be created. This way different samples can restrict
> the
> number of tables created based on their need.
>
> Also, making methods to do force/needBased refresh of tables and data.
> i.e.
> control table
> creation and data refresh.
>
> We can use same jar in web samples and standalone samples.
>
> The methods exposed to the clients of this jar will be dbInit.createDB
> (DBConfigFileName);
> dbInit.createSchema(boolean) - for force/need base table creation,
> dbInit.createData(boolean)-
> for force/need base data refresh.
>
> Can be more granular - like which table to create/data to refresh -
> but then the whole referntial integrity will need to be taken care, So to
> keep it simple - at present - its all tables/none , not selective.
>
> I am assuming that the table structure is internal knowledge of this
> util,
> i.e. not allowing externally defining table structures etc. (sim. to
> what we
> have at present in rdb). Only flexibility is - which are the tables
> required
> by the current client. Will that suffice for the current need? We can add
> that later if it is essential for some apps/samples.
>
> Pasting here the structure of DBConfig.xsd. See if this will meet the
> requirements. Can add database vendor name to support different databases
> like Derby, DB2, MySQL etc.
> One question here is -
> For DB2 database creation - from java, how to do this? There are ways for
> this in MySQL and Derby but could not find for DB2, any pointers?
>
> Below is the xsd.
> _________________________________________________________________________________
>
> <?xml version="1.0" encoding="UTF-8"?>
> <!--
> Licensed to the Apache Software Foundation (ASF) under one
> or more contributor license agreements. See the NOTICE file
> distributed with this work for additional information
> regarding copyright ownership. The ASF licenses this file
> to you under the Apache License, Version 2.0 (the
> "License"); you may not use this file except in compliance
> with the License. You may obtain a copy of the License at
>
> http://www.apache.org/licenses/LICENSE-2.0
>
> Unless required by applicable law or agreed to in writing,
> software distributed under the License is distributed on an
> "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
> KIND, either express or implied. See the License for the
> specific language governing permissions and limitations
> under the License.
> -->
> <xsd:schema
> xmlns:DBConfig="http:///org.apache.tuscany.das.rdb/DBConfig.xsd"
> xmlns:xsd="http://www.w3.org/2001/XMLSchema"
> elementFormDefault="qualified"
> targetNamespace="http:///org.apache.tuscany.das.rdb/DBConfig.xsd">
>
> <xsd:element name="DBConfig" type="DBConfig:DBConfig"/>
>
> <xsd:complexType name="DBConfig">
> <xsd:sequence>
> <xsd:element maxOccurs="1" minOccurs="1" name="ConnectionInfo"
> type="DBConfig:ConnectionInfo"/>
> <xsd:element maxOccurs="1" minOccurs="1" name="TableList"
> type="DBConfig:TableList"/>
> </xsd:sequence>
> <xsd:attribute name="forceRecreate" type="xsd:boolean"/>
> <xsd:attribute name="forceDataRefresh" type="xsd:boolean"/>
> </xsd:complexType>
>
> <xsd:complexType name="ConnectionProperties">
> <xsd:attribute name="driverClass" type="xsd:string"/>
> <xsd:attribute name="databaseURL" type="xsd:string"/>
> <xsd:attribute default="" name="userName" type="xsd:string"/>
> <xsd:attribute default="" name="password" type="xsd:string"/>
> <xsd:attribute default="0" name="loginTimeout" type="xsd:int"/>
> </xsd:complexType>
>
> <xsd:complexType name="ConnectionInfo">
> <xsd:sequence>
> <xsd:element maxOccurs="1" minOccurs="0"
> name="ConnectionProperties"
> type="DBConfig:ConnectionProperties"/>
> </xsd:sequence>
> <xsd:attribute name="dataSource" type="xsd:string"/>
> </xsd:complexType>
>
> <xsd:complexType name="TableList">
> <xsd:sequence>
> <xsd:element maxOccurs="unbounded" minOccurs="0" name="TableName"
> type="xsd:string"/>
> </xsd:sequence>
> </xsd:complexType>
> </xsd:schema>
>
>
> On 4/10/07, Luciano Resende <lu...@gmail.com> wrote:
>
>>
>> Hi Amita
>>
>> Today, we have couple of DAS sample applications (companyWeb,
>> customer,
>> das-service) and they mostly rely on same set of databases table and the
>> solution we have today is to have the actual derby canned db checked in
>> and
>> copied when it need to be used. This per si is a problem, but also,
>> if you
>> want to use the sample with another db (e.g MySQL) you would have to
>> create
>> the canned DB yourself. There is also a small issue when performing
>> automated integration testings using htmlUnit, that we need a way to
>> refresh
>> the data to it's initial status, to allow running the test again without
>> having to re-copy the canned databases.
>>
>> The idea behind Tuscany-863 is to try solve these issues mentioned
>> above,
>> so the solution should be something that we could share between all the
>> sample applications, maybe a module that would create a jar to handle
>> this
>> canned db, and the applications using the canned DBs would include
>> the jar
>> to handle creation population and refreshing the canned DB data.
>>
>> The patch you produced for Tuscany-863 is embedded on the companyWeb
>> sample, so I think it would be better to investigate the possibility to
>> move
>> it to it's own module. I'm also open to hear other possible
>> solutions, or
>> approaches, that would address the scenarios mentioned above.
>>
>> Thoughts ?
>>
>> --
>> Luciano Resende
>> http://people.apache.org/~lresende
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: [DAS] Automatically Creating sample canned databases
Posted by Amita Vadhavkar <am...@gmail.com>.
Hi Luciano,
Yes, I am making a util jar for that. Please check all the below details and
let me know
yout suggestions.
Trying to reuse part of DAS config.xsd's (ConnectionInfo portion ) to supply
the connection params and adding a new element to xsd to list database table
names that need to be created. This way different samples can restrict the
number of tables created based on their need.
Also, making methods to do force/needBased refresh of tables and data. i.e.
control table
creation and data refresh.
We can use same jar in web samples and standalone samples.
The methods exposed to the clients of this jar will be dbInit.createDB
(DBConfigFileName);
dbInit.createSchema(boolean) - for force/need base table creation,
dbInit.createData(boolean)-
for force/need base data refresh.
Can be more granular - like which table to create/data to refresh -
but then the whole referntial integrity will need to be taken care, So to
keep it simple - at present - its all tables/none , not selective.
I am assuming that the table structure is internal knowledge of this util,
i.e. not allowing externally defining table structures etc. (sim. to what we
have at present in rdb). Only flexibility is - which are the tables required
by the current client. Will that suffice for the current need? We can add
that later if it is essential for some apps/samples.
Pasting here the structure of DBConfig.xsd. See if this will meet the
requirements. Can add database vendor name to support different databases
like Derby, DB2, MySQL etc.
One question here is -
For DB2 database creation - from java, how to do this? There are ways for
this in MySQL and Derby but could not find for DB2, any pointers?
Below is the xsd.
_________________________________________________________________________________
<?xml version="1.0" encoding="UTF-8"?>
<!--
Licensed to the Apache Software Foundation (ASF) under one
or more contributor license agreements. See the NOTICE file
distributed with this work for additional information
regarding copyright ownership. The ASF licenses this file
to you under the Apache License, Version 2.0 (the
"License"); you may not use this file except in compliance
with the License. You may obtain a copy of the License at
http://www.apache.org/licenses/LICENSE-2.0
Unless required by applicable law or agreed to in writing,
software distributed under the License is distributed on an
"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
KIND, either express or implied. See the License for the
specific language governing permissions and limitations
under the License.
-->
<xsd:schema xmlns:DBConfig="http:///org.apache.tuscany.das.rdb/DBConfig.xsd"
xmlns:xsd="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified"
targetNamespace="http:///org.apache.tuscany.das.rdb/DBConfig.xsd">
<xsd:element name="DBConfig" type="DBConfig:DBConfig"/>
<xsd:complexType name="DBConfig">
<xsd:sequence>
<xsd:element maxOccurs="1" minOccurs="1" name="ConnectionInfo"
type="DBConfig:ConnectionInfo"/>
<xsd:element maxOccurs="1" minOccurs="1" name="TableList"
type="DBConfig:TableList"/>
</xsd:sequence>
<xsd:attribute name="forceRecreate" type="xsd:boolean"/>
<xsd:attribute name="forceDataRefresh" type="xsd:boolean"/>
</xsd:complexType>
<xsd:complexType name="ConnectionProperties">
<xsd:attribute name="driverClass" type="xsd:string"/>
<xsd:attribute name="databaseURL" type="xsd:string"/>
<xsd:attribute default="" name="userName" type="xsd:string"/>
<xsd:attribute default="" name="password" type="xsd:string"/>
<xsd:attribute default="0" name="loginTimeout" type="xsd:int"/>
</xsd:complexType>
<xsd:complexType name="ConnectionInfo">
<xsd:sequence>
<xsd:element maxOccurs="1" minOccurs="0" name="ConnectionProperties"
type="DBConfig:ConnectionProperties"/>
</xsd:sequence>
<xsd:attribute name="dataSource" type="xsd:string"/>
</xsd:complexType>
<xsd:complexType name="TableList">
<xsd:sequence>
<xsd:element maxOccurs="unbounded" minOccurs="0" name="TableName"
type="xsd:string"/>
</xsd:sequence>
</xsd:complexType>
</xsd:schema>
On 4/10/07, Luciano Resende <lu...@gmail.com> wrote:
>
> Hi Amita
>
> Today, we have couple of DAS sample applications (companyWeb, customer,
> das-service) and they mostly rely on same set of databases table and the
> solution we have today is to have the actual derby canned db checked in
> and
> copied when it need to be used. This per si is a problem, but also, if you
> want to use the sample with another db (e.g MySQL) you would have to
> create
> the canned DB yourself. There is also a small issue when performing
> automated integration testings using htmlUnit, that we need a way to
> refresh
> the data to it's initial status, to allow running the test again without
> having to re-copy the canned databases.
>
> The idea behind Tuscany-863 is to try solve these issues mentioned
> above,
> so the solution should be something that we could share between all the
> sample applications, maybe a module that would create a jar to handle this
> canned db, and the applications using the canned DBs would include the jar
> to handle creation population and refreshing the canned DB data.
>
> The patch you produced for Tuscany-863 is embedded on the companyWeb
> sample, so I think it would be better to investigate the possibility to
> move
> it to it's own module. I'm also open to hear other possible solutions, or
> approaches, that would address the scenarios mentioned above.
>
> Thoughts ?
>
> --
> Luciano Resende
> http://people.apache.org/~lresende
>