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]
>
>
