Martin, Thank you for getting back to me and thanks for the pointer to NextObjects!
I understand that the procedures and functions would have to be exported in RDBMS specific syntax but these could simply be text elements which could be edited as necessary. Not ideal but far from useless I'd think since many of us work within a single RDBMS during a projects lifecycle anyway. A flag could be set to toggle the dump of any platform specific information. The idea behind the "dump db info" plugin is really just a convienience plugin to quickly see what features a JDBC driver supports. There are lots of JDBC drivers out there and this would provide a quick way to dump the critical information for a JDBC driver for a developer. Clearly it does nothing for the runtime environment of Torque so it's usefulness in that context is certainly debatable. I would assume that anything implemented for Torque should be done so through standard JDBC API's using standard SQL syntax. It seems like the focus on Torque is really the runtime environment and that any DB administration functions are to be maintained in support of that goal. Is this a fair assesment? Many Thanks! Jamey -----Original Message----- From: Martin Poeschl [mailto:[EMAIL PROTECTED] Sent: Saturday, December 06, 2003 10:08 AM To: Apache Torque Developers List Subject: Re: Status the primary goal of the torque generator was to generate everything needed to use the torque runtime environment (om/peer model, sql scripts to create the db) based on the existing functions it should be possible to extend it as needed ... James Courtney wrote: >Hey Torque developers, > >I was hoping a couple of you could take a minute to bring me up to speed on some of >the features of the project and it's direction to see if it will meet some of my >companies needs. Thank you in advance for your time and help. > >Our company uses Maven for the majority of our projects and we have need of a tool >that will allow us to easily manage various DB schema's and export schema >descriptions to something easy to track in source control. Basically I've inherited >an old Oracle schema for our app with little documentation and a trail of old SQL >Scripts and we're planning a migration to SQL Server and some new application schema >changes very soon so I need to get my ducks in a row. We are CVS dependent and being >able to track schema changes in a text format allows for nice diffing between >revisions. My managment is also unlikely to spring for a tool like ER/Win, I'm not >sure I need that much functionality, and the ER/Win data files don't diff well at >all. Currently we have an existing persistence layer so honestly we wouldn't be >making much use of that aspect of Torque for now so I'm mainly concerned with it's >ability to help me with administrative DB schema management and work smoothly with >Oracle and SQL Server (which the new Microsoft drivers seem to allow it to do). >Torque seems to provide some of this functionality and I was wondering what the >"plan" was for the Torque project with regard to more advanced schema management with >regards to some of the following subjects. > > you can use nextobjects if you need a gui to edit the schema.xml files ... http://www.devaki.org/ >1) Currently only the table and view structures are exported from the schema, what >about procedures, functions, users, etc. > > not supported at the moment ... i don't think there is a way to handle this for different rdbms ... >2) Does Torque allow one to compare physical DB schemas, xml schema files, and SQL >scripts for differences and to generate SQL Scripts for performing those differences? > > not supported at the moment ... Steve Garcia is working on this and i hope he'll send some patches soon ;-) >3) Are there any nice XSLT templates out there for turning Torque schema XML into >nice DB documentation? > > there is a task to generate html or xml docs .. the xml docs are in anakia format so you can integrate it with your other maven xdocs >4) Has anyone though of making a very simple Maven target or Torque task called >torque:driverInfo or something that dumps out all the interesting driver information >about supported features and syntax (see java.sql.DatabaseMetaData object methods) >for the user to see? > > no, but it should be easy to do it ... what's the use case for this extension?? >If I convince myself that Torque offers enough features to be useful to me I'm >perfectly willing to actively contribute to the effort with bug reporting and code >including a class for point 4 above and extensions provided in point 1. If I can't >get what I need from Torque I probably can't justify the time to actively contribute >much given my work schedule so please help me understand what direction the project >is taking and what features I can expect to make use of and if you think any of my >questions or ideas above would make sense. > > any extension to torque is welcome .. but it doesn't help to have cool features for on rdbms if they are not supported on all others .. so if you paln to extend toprque make sure the extension will also work on other rdbms .. martin --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
