[Dbix-class] RFC: Database capabilities
darren at DarrenDuncan.net
Fri Mar 31 00:01:17 CEST 2006
At 19:03 +0100 30/3/06, Matt S Trout wrote:
>Paul Makepeace wrote:
> > I'd like to be able to talk to DBIC in SQL rather than its own dialect
>> of perl data structures. I'm thinking an SQL parser that generated DBIC
>> code. (A consequence of this is abstracting some of the RDMBS dialect
>> differences away *at the SQL level*.)
>Hmm, wonder if we can do an "explicit S::Abstract tree <-> SQL statement"
>relationship such that we can convert losslessly both ways? If we can, can we
>encapsulate the relationship <-> ON clause stuff to achieve the same thing?
>That'd be really kinda nice, esp. since we could then specify the production
>for stuff like LDAPQuery and SPARQL as well when we look at other storages. Is
>this feasible even for SQL? (I Am Not A Parser Expert)
>Darren, this is your sort of area - could Rosetta buy us this? Is Rosetta
>remotely usable at the moment? Whatever the answers to the previous two
>questions, does this sound good or am I on crack again?
Since you asked ...
Rosetta is unuseable at the moment, and probably will continue to be
for a few weeks or months more yet, so in the short term you
shouldn't depend on it; only consider it for longer term use. It
consists mainly of incomplete design documentation at the moment, and
there isn't enough code to do anything with yet.
Also, depending on how closely you've been paying attention, what
Rosetta *is* has changed since last fall, though its overall goals of
making it easier to develop portable applications remains.
The current design goal of Rosetta is that it is a truly-relational
DBMS of its own, with a single core interface and swappable back-ends
(a back-end can be pure Perl or implemented over another database
like a DBI-accessed one), and its native command language resembles a
cross between Perl 6 and relational algebra; you input this either as
Perl data structures resembling an AST, or in string form. All joins
are natural and/or cross joins, and all result columns have distinct
names, which is mappable back to the original; views are updateable
and can be treated like base tables for all intents and purposes.
You use Rosetta like you use DBI, but that all back-ends take an
identical language/dialect rather than different ones, and the
Rosetta DBMS has built-in features that many other DBMS do not,
including user-defined type support.
When you use the API, you are *not* using SQL, and the API does not
try to look like SQL; it is meant to be *better* than SQL, and able
to represent anything in the real world, including things SQL can't.
Therefore, Rosetta and/or its language is a suitable interchange
format which any type of query or command, in any language, can be
parsed to, or be generated from, including those written in SQL.
Such parsers/generators for other languages than Rosetta's native one
are not part of the core, but can be done as separately distributed
extensions (like DBI drivers, wrappers are separate).
Go to http://search.cpan.org/dist/Rosetta/ and read the DESCRIPTION
for Rosetta.pm plus the top half of Language.pod (the parts that do
*not* say "old/to remove") for the most up to date information.
Forgive me that I can't talk about this too much in the short term,
as I have a new and unrelated paying project that is due soon.
-- Darren Duncan
More information about the Dbix-class