2005-04-03 Darren Duncan <[EMAIL PROTECTED]> --------------------------------------------------
I am now pleased to announce the second developer release of my Rosetta rigorous database portability library, currently featuring the SQL::Routine module. (Considering the huge number of changes since the first developer release, 2004-08-07, I'll just provide a re-introduction rather than a delta.)
The module set that can be broadly referred to as the 'Rosetta Framework' is composed of the following 5 distributions, which should appear on your favorite CPAN mirrors within the next few hours or days; all of them are in native Perl 5 versions, and the 2 most mature ones are also in native Perl 6 versions (useable soon with Pugs or Parrot):
Native Perl 5 versions:
1. Locale-KeyedText-1.03.tar.gz
2. SQL-Routine-0.58.tar.gz (dep on 1)
3. Rosetta-0.43.tar.gz (dep on 1, 2); also holds Rosetta::Validator
4. SQL-Routine-SQLBuilder-0.17.tar.gz (dep on 2)
5. Rosetta-Engine-Generic-0.17.tar.gz (dep on 1, 2, 3, 4)Native Perl 6 versions: http://freepan.org/modules.html
1. http://tpe.freepan.org/repos/duncand/Locale-KeyedText/ 2. http://tpe.freepan.org/repos/duncand/SQL-Routine/ (dep on 1) 3. N/A 4. N/A 5. N/A
(Note that the Perl 6 modules all use language features, such as objects, which Pugs doesn't yet support, but should in a month or so given its excellent progress so far. They are as correct as humanly possible considering this fact. At the present time they are also the only/first database related Perl 6 modules that exist, as far as I know.)
My CPAN maintainer ID is DUNCAND. In addition to CPAN, you should also find the Perl 5 modules here: http://darrenduncan.net/d/perl/ .
I welcome and encourage any and all feedback on these modules that you can give me. It would be VERY helpful to me. I am also grateful if you can find these modules useful in your own work. Likewise, if you have any questions, I will do my best to answer them. If you wish to help with their development in some way, I am also open to such offers.
Each of these 5 distributions is independently useful of the whole so-called framework, and I strongly encourage you to use them independently. Each one also has a set of POD documentation with it, so you should look at that to best understand them; however, a brief intro for each follows here:
----------
1. Locale::KeyedText can be used for any type of application or library.
Locale::KeyedText (LKT) provides a simple but effective mechanism for applications and modules that empowers single binaries to support N locales or user types simultaneously, and that allows any end users to add support for new languages easily and without a recompile (such as by simply copying files), often even while the program is executing.
This module is the most mature and is fully tested; dev status of '(R)eleased'.
This module is registered with the Perl 5 Module List.
It can be used in your programs immediately.
----------
2. SQL::Routine can be used in any SQL using environment, regardless of what you use to bridge with databases.
The SQL::Routine (SRT) Perl 5 module provides a container object that allows you to create specifications for any type of database task or activity (eg: queries, DML, DDL, connection management) that look like ordinary routines (procedures or functions) to your programs; all routine arguments are named.
SQL::Routine can broadly represent, as an abstract syntax tree (a cross-referenced hierarchy of nodes), code for any programming language, but many of its concepts are only applicable to relational databases, particularly SQL understanding databases. It is reasonable to expect that a SQL:2003 compliant database should be able to implement nearly all SQL::Routine concepts in its SQL stored procedures and functions, though SQL:2003 specifies some of these concepts as optional features rather than core features.
SQL::Routine is intended to be used by an application in place of using actual SQL strings (including support for placeholders). You define any desired actions by stuffing atomic values into SQL::Routine objects, and then pass those objects to a compatible bridging engine that will compile and execute those objects against one or more actual databases. Said bridge would be responsible for generating any SQL or Perl code necessary to implement the given SRT routine specification, and returning the result of its execution.
SQL::Routine is also intended to be used as an intermediate representation of schema definitions or other SQL that is being translated from one database product to another.
See the module's SYNOPSIS for examples such as how to define DOMAIN, TABLE, VIEW database schema objects, as well as routines for doing SELECTs and INSERTs of single or multiple rows (one of which also opens and closes a db connection).
This module is the next most mature and the tests probably cover 70-80% of it; dev status of '(a)lpha'.
This module is registered with the Perl 5 Module List.
It can be used in your programs immediately.
----------
3. SQL::Routine::SQLBuilder can be used in any SQL using environment.
It will generate ANSI/ISO SQL:2003 and other SQL variants from SQL::Routine models, and serves as a reference implementation of that functionality.
This module is pre-alpha development status and has no tests written for it yet, other than that it compiles.
----------
4.1 The Rosetta Perl 5 module defines a complete and rigorous API for database access that provides hassle-free portability between many dozens of database products for database-using applications of any size and complexity, that leverage all sorts of advanced database product features. The Rosetta Native Interface (RNI) allows you to create specifications for any type of database task or activity (eg: queries, DML, DDL, connection management) that look like ordinary routines (procedures or functions) to your programs, and execute them as such; all routine arguments are named.
One of the main goals of Rosetta is similar to that of the Java platform, namely "write once, run anywhere". Code written against the RNI will run in an identical fashion with zero changes regardless of what underlying database product is in use. Rosetta is intended to help free users and developers from database vendor lock-in, such as that caused by the investment in large quantities of vendor-specific code. It also comes with a comprehensive validation suite that proves it is providing identical behaviour no matter what the underlying database vendor is.
The Rosetta module does not talk to or implement any databases by itself; it is up to separately distributed Engine modules to do this. You can see a reference implementation of one in the Rosetta::Engine::Generic module.
Rosetta is conceptually a DBI wrapper, whose strongest addition is SQL generation, but it also works without the DBI, and with non-SQL databases; it is up to each Engine to use or not use DBI, though most will use it because the DBI is a high quality and mature platform to build upon.
The choice between using DBI and using Rosetta seems to be analogous to the choice between the C and Java programming languages, respectively, where each database product is analogous to a hardware CPU architecture or wider hardware platform. The DBI is great for people who like working as close to the metal as possible, with direct access to each database product's native way of doing things, those who *want* to talk to their database in its native SQL dialect, and those who want the absolute highest performance. Rosetta is more high level, for those who want the write-once run-anywhere experience, less of a burden on their creativity, more development time saving features, and are willing to sacrifice a modicum of performance for the privilege.
4.2 The Rosetta::Validator Perl 5 module is a common comprehensive test suite to
run against all Rosetta Engines. You run it against a Rosetta Engine module to
ensure that the Engine and/or the database behind it implements the parts of
the Rosetta API that your application needs, and that the API is implemented
correctly. Rosetta::Validator is intended to guarantee a measure of quality
assurance (QA) for Rosetta, so your application can use the database access
framework with confidence of safety.
Alternately, if you are writing a Rosetta Engine module yourself, Rosetta::Validator saves you the work of having to write your own test suite for it. You can also be assured that if your module passes Rosetta::Validator's approval, then your module can be easily swapped in for other Engine modules by your users, and that any changes you make between releases haven't broken something important.
Rosetta::Validator would be used similarly to how Sun has an official validation suite for Java Virtual Machines to make sure they implement the official Java specification.
This module is pre-alpha development status.
This module is registered with the Perl 5 Module List.
Since Rosetta requires an Engine to be useful (as DBI requires a driver), it does not have its own test suite except for that it compiles. However, the following Generic Engine module does, and so its test suite also tests Rosetta itself.
----------
Rosetta::Engine::Generic is a catch-all Engine for any DBI-supported SQL database.
The Rosetta::Engine::Generic Perl 5 module is a functional but quickly built Rosetta Engine that interfaces with a wide variety of SQL databases. Mainly this is all databases that have a DBI driver module for them and that support SQL natively; multi-database DBD modules like DBD::ODBC are supported on equal terms as single-database ones like DBD::Oracle. I created this module to be a "first line of support" so that Rosetta works with a variety of databases as soon as possible.
This module has a Rosetta::Validator-based test suite which currently exercises its ability to connect to and disconnect from a database, and get a list of automatically visible database instances. In the near future it will also implement typical DDL and DML operations, at which point it should be generally useful.
----------
I welcome and encourage any and all feedback on these modules that you can give me. It would be VERY helpful to me. I am also grateful if you can find these modules useful in your own work. Likewise, if you have any questions, I will do my best to answer them. If you wish to help with their development in some way, I am also open to such offers.
Thank you and have a good day. -- Darren Duncan
