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 <[EMAIL PROTECTED]> 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
