[VPM] ANNOUNCE: SQL-Routine/Rosetta developer release #2 - in Perl 6 too

Darren Duncan darren at DarrenDuncan.net
Mon Apr 4 01:30:04 PDT 2005


2005-04-03   Darren Duncan <perl at DarrenDuncan.net>
--------------------------------------------------

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


More information about the Victoria-pm mailing list