-* Some way to deeply check to schema objects, e.g., for testing I
- parse a MySQL schema, translate to Oracle, then parse the created
- Oracle schema and want to check the two schema objects.
+* Parse FOREIGN KEY / REFERENCES with SQLite as the latest version
+ supports them.
-* Explore some way to pass an open database handle instead of a
- schema and then query through DBI methods to get the schema
- definition, somewhat a la SQL::Schema (which only works with
- Oracle right now)
+* Add Parser/Producer for ActiveRecord::Migration
+ [http://api.rubyonrails.com/classes/ActiveRecord/Migration.html].
-* Add "CREATE VIEW" support to existing parsers
+* The regular Sybase parser is only just functional. If you are
+ interested in using Sybase, I would suggest serializing the schema
+ (via YAML or Storable) using the DBI-Sybase parser and then
+ manipulating that as you see fit.
+
+* Add more DBI parsers! These have the potential to be very
+ thorough and far faster than parsing text files with
+ Parse::RecDescent.
* At least allow more pass-through of INSERT, DELETE, and UPDATE
statements
* Add INSERT statements for xSV, Excel parsers to automatically
create INSERTs for each row of data in the source file
-* Fix Sybase parser (which means really figuring out the dump format
- we want to parse -- Sam, can you recommend something?)
-
-* Add more parsers (though I need some ideas -- probably at least
- one for SQLite since we have that producer)
-
* Somehow merge ClassDBI producer with CGI::FormBuilder or Template
Toolkit and some sort of automated CGI builder to create
view/create/edit/delete forms for objects based on schema defs
to distribute the tables so that the lines don't overlap so badly
* Integrate more with some standard XML schema representations,
- maybe like Torque DB (http://db.apache.org/torque/), add parsers
- and producers
+ maybe like Torque DB (http://db.apache.org/torque/). We've
+ started messing around with XMI, too, but it isn't quite usable.
* Possibly write a basic ANSI-92 SQL parser which could be extended
- when writing other new parsers -- can anyone help me nail down a
- URL that describes in detail that spec?
+ when writing other new parsers.
+
+* Make as many "required" modules as possible optional. This will
+ require support in the Makefile, the tests, and the modules
+ themselves (they'll need to die gracefully if prerequisites are
+ not installed).
+
+* Support for precompiled Parse::RecDescent grammars.
+- This is easy and I've done it locally with the DB2 parser - Jess
+
+* More code generation producers, such as Java, PHP, and Python.
-* Expand sql_translator.cgi to be a frontend for all producer
- formats, not just the graphical ones; also improve the interface
+* Integrate Module::Pluggable as a replacement for the _list method.