ONE DEVELOPMENT TRACK

r0.14 - Create the Locale::KeyedText module and other Locale modules.  These
will be needed by the other code modules. The french module will only contain
mock text (to be replaced later) since I'm not fluent in non-english languages.

r0.15 - Flesh out SQL::ObjectModel, bringing it up to DataDictionary state.

r0.16 - Create modules Rosetta::Engine, Rosetta::Connection,
as well as Rosetta::Driver::Null.

* Start Rosetta-Drivers distribution, having just module ::Native.  This driver
should be able to create and delete databases, open and close connections to
them, and add and remove tables, as well as verify either.  May need some
"user" details as well.  Note that part of creating a database is to make a
root user.

* Add to Rosetta-Drivers the ::MySQL module, which is able to connect to or
disconnect existing databases (but not create or remove them yet), and
create/verify/delete tables.  A MySQL specific driver option will allow one to
choose the default table type to use, which would determine whether foreign
keys are enforceable or not.  Also make support modules like ::DBIWrapper and
::SQLWriter.

* Add to Rosetta-Drivers the ::Oracle module, which I know how to use, but
don't have a database install to test against yet.

* Update other modules to support working with table records.  Add
::Transaction and ::Cursor modules.

* Update existing drivers to support working with records from one table at a
time.  This should enable the SYNOPSIS to work.

* Update existing drivers to support working with records from multiple tables
at a time.

* Start working on the ::Validator modules.

* Start working on the ::Emulator modules.

* Start working on the ::Proxy modules.

* Start adding support for stored procedures and other features.

* Whatever else needs doing ...

ANOTHER DEVELOPMENT TRACK

* Connect to (or open) an existing database as a registered or anonymous user,
which establishes a current working context for doing anything else, and close
it; multiple simultaneous connections should be supported; the database and
users must already exist.

* Create new database instances or remove them, if that can be done easily.

* Create new users in the current database or remove them or alter their
privileges or validate any settings for user existence or privileges; note that
Rosetta will not enforce user privileges or lacks of them for any RDBMS
products that don't do this internally.

* Create tables (including temporary) within the default schema context that
you connected to (eg: an Oracle "user/schema" in an "instance"), with
nullability or unique key (including primary key) or foreign key constraints or
indexes that are not constraints or default column values, and alter or remove
or validate them, assuming the connected user has said privileges; the same
operations will also be supported against neighbouring contexts (if any) for
which said user is permitted; note that Rosetta will not enforce any
constraints on tables as that is up to the RDBMS product, although it may try
to enforce some constraints in a far-away release for RDBMS products that don't
do it themselves, but that would be slower and less reliable.

* Create or alter or remove sequences within the default schema context, and
use them in table definitions or data modifying operations.

* Scan an existing database and create a data dictionary (as objects) that
describes its tables and sequences, including any constraints that the database
knows about.

* Start a transaction, which is an operating context within which all table
data changes must succeed or none will be saved, and end it either with a
commit (keep changes) or rollback (discard changes); this type of data
integrity will not work unless the RDBMS product being used supports
transactions; far-off releases of Rosetta may implement transactional data
integrity at the Perl level for non-supporting RDBMS products, but using a
supporting RDBMS is better; multiple simultaneous transactions within a single
database connection should be supported.

* Select data from single or related multiple tables, including the use of
equal or left outer joins, full and unique unions (similar to full outer
joins), derived tables (in sql-from), sub-selects (in sql-where), hierarchical
queries (eg: an Oracle start-with and connect-by), and including the use of
calculations or formulas (including logicals like choose-when) in the returned
column list or in the row filter or grouping conditions; the select results can
be accessed either with row cursors (memory efficient) or all at once with an
array (for small result sets only); also, insert or update or delete against
single tables.

* Obtain locks on table data for when you want atomic selects and updates, and
release them; the same caveats that apply to transaction support in the RDBMS
product being used also applies here.

* Utilities for backing up or restoring the tables in a database, both schema
and data, either with another database or a set of text files.

* Insert or update or delete against multiple related related tables at once,
as if they were a single table; the Rosetta objects that define the multiple
table selection will be used to know how to map said data changes against the
correct tables; it may not be possible for Rosetta to issue changes against
some selects, since some required mapping information may be lacking; in that
case, the application logic will have to handle it against single tables.

* Create stored procedures and functions within the default schema context that
you connected to, and alter or remove them, and invoke them directly; initially
this feature will require you to define a separate version of a stored
procedure or function for each RDBMS product you are going to use, because it
is too difficult to implement an abstracted definition and generation of such
things for earlier Rosetta releases; there are two ways to do this, one of
which involves writing the functionality in pure Perl (which can be done once
for all RDBMS products, particularly those that don't support stored procedures
at all, but is slower), and the other way involves a hand-crafted SQL string
implementing the procedure plus a shim Perl function that calls it; your main
application is still RDBMS generic because any multiplicity of stored procedure
implementations will be keyed to a Rosetta driver, so the right one is used at
the right time; in any event, the standard RNI means of calling a stored
procedure is calling something that looks externally like a Perl function,
which won't change, so you will still have to make at least the interface in
Perl; also modify or delete them, or validate those added through Rosetta.

* Call stored functions within select queries and so forth; this would likely
only work when the stored item is actually in the database, and is not a pure
Perl implementation.

* Create stored triggers, with the same caveats as stored procedures and
functions regarding multiplicity of implementations, or update or remove them,
or validate those added through Rosetta; initially this feature will not work
at all unless the underlying RDBMS supports triggers, since early Rosetta
releases will not interrupt or scan data UID operations to implement triggers
in Perl.

* Create or alter or remove "public synonyms" in Oracle or other RDBMS that
support the concept of this convenient aliasing system.

* Create views, which are select queries whose definitions are stored in a
database for convenience and pre-processing speed, within the default schema
context that you connected to, and alter or remove them; validating views will
at first only be possible if the same version of Rosetta created them, because
it is done by a simple string compare for databases that store views as sql
statements, so that the sql won't have to be parsed.

* Also scan the views in an existing database and parse their definition sql so
that generated data dictionaries can describe both tables, views, and seqs.

* Also extract the stored procedures and functions and triggers and so forth in
their raw form, unparsed, for backup or restore to the same kind of RDBMS that
they came from.

* Emulate other database interfaces (like DBI or ODBC or OCI or whatever) on
top of Rosetta; this would require being able to parse SQL like for data
selection or modification, or table and view creation, and so forth, as well as
pass through unparsed the creation sql of stored procedures and functions and
triggers for use as is (latter not portable).

* Get around to parsing or generating sql for stored procedures or functions or
triggers, and representing them abstractly for a data dictionary.

* Whatever else is needed.
