[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