Have created das/plugin which has goal - generate and phase
generate-resources. As a verification test, in
the same pom.xml (das/plugin), I have created a profile called -
plugin-test. When invoked, it references
das/rdb/target/dastest database and creates required model xsds. So this
profile assumes
that the pre-req rdb-das is compiled and tested - as test phase of rdb-das
creates this database.
Regards,
Amita
On Nov 30, 2007 5:31 PM, Amita Vadhavkar <[EMAIL PROTECTED]> wrote:
> After discussing how further to integrate with SDO tools, I will work on
> those changes.
>
> Meanwhile, created a plugin with goal - generate, phase -
> generate-resources under - tuscany-das-plugin
> Also, tested same to be working by creating a test under
> tuscany-das-tools-test. Following this structure similar to what is there in
> SDO.
> Please see if you have any comments on this structure, else will do the
> check-ins.
>
> Regards,
> Amita
>
>
> On Nov 30, 2007 11:30 AM, Amita Vadhavkar < [EMAIL PROTECTED]>
> wrote:
>
> > Let me try to understand this more clearly.
> >
> > The tool checked in under das-tools does 2 things
> > 1) it just wraps Apache Torque to introspect DB SChema to dump it into a
> > simple XML file - this is entirely Torque functionality, already in use by
> > Torque users
> > 2) it directly uses DB Connection via Torque (to first get the XML as in
> > and further processes it) to form SDO Model XSDs
> > 3) It optionally can use the XML file from 1) and form SDO Model XSDs.
> >
> > So this tool is capable of genrating SDO Model XSDs without any
> > dependency on SDO and with dependency on Torque. May be the
> > appropriate place for this tool is under sdo-tools rather than das-tools
> > as it does not as such do any Data Access, but this tool is RDB
> > centric and SDO has nothing to do with the nature of data source,
> > whether it is DB or XML or...so I tried to keep it under das-tools.
> >
> > When you say "use SDO Tools to generate Static SDO", do you mean Static
> > SDO "Objects" or static SDO Model "XSDs"?
> > Static Model XSDs are already generated by das-tool ( and as I mentioned
> > in last mail's exception stack trace, there are exceptions thrown
> > in XSDHelper.generate() method when I tried the path DB->RDB DAS Code
> > Reuse to form in-mem SDOType -> XSDHelper.generate() and so
> > tried using Torque. Thus instead of dependency on SDO and EMF both ,
> > das-tools has dependency only on Torque).
> >
> > TypeHelper or HelperContext from SDO provide a way to register Static
> > Types provided through XSDs in the Context and form SDO
> > Instance Objects from these. The tool under tuscany-das-tools can be
> > further integrated with this SDO feature to get the Object Instance
> > of Static SDO Types using TypeHelper / HelperContext to first register
> > the Types stated in the Static Model XSD formed by tuscany-das-tool.
> > Is this what you are proposing? This further integration can result into
> > -
> >
> > a> use generate option (XSD2JavaGen) from sdo-plugin/tool to generate
> > interfaces and impls of Types stated in SDO Model XSDs, as we do
> > right now in rdb-das for config.xsd, company.xsd...during mvn compile.
> > With this during mvn compile phase, if the DB connection is available
> > OR if the torque based schema.xml of DB is available, the user will be
> > able to get Static SDO Types interfaces/impls code generation along with
> > auto generation of SDO Model XSDs.
> >
> > b> also some util methods like createDataObject("DOName") can be
> > supported.
> >
> > a> and b> is already available using SDO Tools, so it will be just
> > integrating it with das-tool to help in end-to-end support for----->
> > DB2JavaGenerator (on same lines as XSD2JavaGenerator) and
> > methods like DataObject DB2XSDGenerator.createDataObject(Name)
> >
> > Please let me know your comments.
> >
> > Regards,
> > Amita
> >
> >
> > On Nov 29, 2007 8:31 PM, Luciano Resende < [EMAIL PROTECTED] > wrote:
> >
> > > I guess that the main scenario for trying to create XML schema from DB
> > > schema is when one wants to create Static SDO from a DB Schema ? Am I
> > > right ? In this case, the user will have to use a DAS tool that
> > > understand the store schema, and then SDO tools to generate the Static
> > > SDO. Would it make sense to try to enhance the user experience and
> > > integrate the two, and the user could only run the SDO tools that
> > > would introspect the database schema when creating the Static SDO ?
> > >
> > > Thoughts ? What the SDO community think about this ?
> > >
> > > On Nov 29, 2007 3:54 AM, Amita Vadhavkar <[EMAIL PROTECTED]>
> > > wrote:
> > > > Please see the checkins under JIRA-1923, Rev 599394
> > > > In-progress- maven plugin creation and assembly file changes to
> > > include
> > > > tools in distribution
> > > >
> > > > Regards,
> > > > Amita
> > > >
> > > >
> > > > On Nov 29, 2007 4:36 PM, Amita Vadhavkar <[EMAIL PROTECTED] >
> > > wrote:
> > > >
> > > > > When trying for tool to convert from DB Schema to SDO Model xsds -
> > > tried
> > > > > using
> > > > > SDO's XSDHelper in one attempt and Apache Torque in another.
> > > > >
> > > > > 1) When using XSDHelper -------------------
> > > > > Tried using XSDHelper.generate () to take as input param the SDO
> > > created
> > > > > by DAS
> > > > > using its dynamic DO creation approach. Saw that when there is a
> > > SDO which
> > > > >
> > > > > contains child DO (like Table STATES will contain table CITIES),
> > > it was
> > > > > giving below exception originating from EMF -
> > > > > java.lang.IllegalArgumentException: The 'no duplicates' constraint
> > > is
> > > > > violated
> > > > > java.lang.IllegalArgumentException : The 'no duplicates'
> > > constraint is
> > > > > violated
> > > > > at org.eclipse.emf.common.util.BasicEList.add (BasicEList.java
> > > :642)
> > > > > at org.eclipse.xsd.impl.XSDNamedComponentImpl.addToSortedList(
> > > > > XSDNamedComponentImpl.java :165)
> > > > > at org.eclipse.xsd.impl.XSDSchemaImpl$3.caseXSDTypeDefinition(
> > > > > XSDSchemaImpl.java:1801)
> > > > > at org.eclipse.xsd.util.XSDSwitch.doSwitch(XSDSwitch.java:201)
> > > > > at org.eclipse.xsd.util.XSDSwitch.doSwitch(XSDSwitch.java:88)
> > > > > at org.eclipse.xsd.util.XSDSwitch.doSwitch(XSDSwitch.java:74)
> > > > > at org.eclipse.xsd.impl.XSDSchemaImpl.adoptContent (
> > > XSDSchemaImpl.java
> > > > > :1819)
> > > > > at org.eclipse.xsd.impl.XSDConcreteComponentImpl.eNotify(
> > > > > XSDConcreteComponentImpl.java:1160)
> > > > > at org.eclipse.emf.ecore.util.EcoreEList.dispatchNotification(
> > > > > EcoreEList.java:234)
> > > > > at
> > > org.eclipse.emf.common.notify.impl.NotifyingListImpl.addUnique(
> > > > > NotifyingListImpl.java:292)
> > > > > at org.eclipse.emf.common.util.BasicEList.add (BasicEList.java
> > > :600)
> > > > > at
> > > org.apache.tuscany.sdo.helper.SchemaBuilder.buildComplexSchemaType(
> > > > > SchemaBuilder.java:352)
> > > > > at org.apache.tuscany.sdo.helper.SchemaBuilder.buildSchema (
> > > > > SchemaBuilder.java:551)
> > > > > at
> > > org.apache.tuscany.sdo.helper.SchemaBuilder.addElement2ComplexType(
> > > > > SchemaBuilder.java:188)
> > > > > at
> > > > >
> > > org.apache.tuscany.sdo.helper.SchemaBuilder.buildComplexSchemaTypeContents
> > > > > (SchemaBuilder.java:306)
> > > > > at
> > > org.apache.tuscany.sdo.helper.SchemaBuilder.buildComplexSchemaType(
> > > > > SchemaBuilder.java:371)
> > > > > at org.apache.tuscany.sdo.helper.SchemaBuilder.buildSchema (
> > > > > SchemaBuilder.java:551)
> > > > > at org.apache.tuscany.sdo.helper.XSDHelperImpl.generate(
> > > > > XSDHelperImpl.java:287)
> > > > > at org.apache.tuscany.sdo.helper.XSDHelperImpl.generate (
> > > > > XSDHelperImpl.java:268)
> > > > >
> > > > > 2) When using Apache Torque--------------------
> > > > > Apache Torque generator task - jdbc worked well and the output
> > > (say
> > > > > schema.xml)
> > > > > could be used by stax to form the SDO Model xsds. This approach
> > > turned out
> > > > > to be
> > > > > simpler and no dependency on SDO and EMF.
> > > > >
> > > > > I am creating tuscany-das-tools to place this utility tool and
> > > also
> > > > > creating maven plugin for same.
> > > > >
> > > > > Suggestions?
> > > > >
> > > > > Regards,
> > > > > Amita
> > > > >
> > > > >
> > > > >
> > > > > On Nov 26, 2007 6:29 PM, Amita Vadhavkar <
> > > [EMAIL PROTECTED]>
> > > > > wrote:
> > > > >
> > > > > >
> > > http://www.mail-archive.com/[email protected]/msg25916.html
> > > > > >
> > > > > > As first attempt trying to create an utility/tool to convert
> > > from DB
> > > > > > Schema to model XSDs -
> > > > > > RDB DAS has a reusable core part which uses DB Metadata to
> > > create SDO
> > > > > > Types and properties. Its result can
> > > > > > be fed to Tuscany SDO's XSDHelper to form XSDs.
> > > > > >
> > > > > >
> > > http://www.mail-archive.com/[email protected]/msg19374.html
> > > > > > DB SChema->SDO->XSD is possible without errors as it comes from
> > > Types
> > > > > > generated from SDO
> > > > > >
> > > > > > Use:
> > > > > > When doing static SDO model based Data Access (not only RDB DAS)
> > > and
> > > > > > model is not available or not up-to-date w.r.t. DB schema -
> > > > > > like cases of rapid prototyping when DB schema is undergoing
> > > changes.
> > > > > >
> > > > > > Limitation:
> > > > > > DB Metadata APIs should support -
> > > > > > DatabaseMetaData.getTables (), getPrimaryKeys(),
> > > getCrossReference(),
> > > > > > ResultSetMetaData.getColumnCount(), getTableName(),
> > > getSchemaName(),
> > > > > > getColumnName(), getColumnType(),
> > > > > >
> > > > > > Suggestions?
> > > > > >
> > > > > > Regards,
> > > > > > Amita
> > > > > >
> > > > >
> > > > >
> > > >
> > >
> > >
> > >
> > > --
> > > Luciano Resende
> > > Apache Tuscany Committer
> > > http://people.apache.org/~lresende<http://people.apache.org/%7Elresende>
> > > http://lresende.blogspot.com/
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > > For additional commands, e-mail: [EMAIL PROTECTED]
> > >
> > >
> >
>
