[Dbix-class] RFC: Database capabilities

[Darren Duncan]

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