support for non-SQL RDBMSs?

[Ted Zlatanov]

I wonder if RDBO can use a non-relational database: Amazon SimpleDB,
Cassandra, HBase, CouchDB, etc.

The columns are neither predefined nor required and may be hierarchical,
there's little to none SQL needed, types are usually not strict, there's
very little foreign key dependency. Inserts tend to be much faster in
parallel and independent.

It would be nice to wrap that with the RDBO model. For Cassandra and
SimpleDB, at least, I can write the glue code. But I don't know the
RDBO internals well enough to tell if this is a matter of some glue or
if there's architectural issues that would make it painful.

Ted

[Peter Karman]

John may contradict me, but here's my 2c.

RDBO is very SQL-centric. I had a similar idea with regard to LDAP
last year, and I though I explored DBD::LDAP for awhile, I ended up
writing Net::LDAP::Class with a similar API and design pattern as RDBO
(including the use of Rose::Object) but from scratch.

So I wouldn't recommend trying to retrofit non-SQL DB support into the
RDBO infrastructure, but I *can* recommend Rose::Object as a good OO
framework (the other being Moose) and RDBO as a good design pattern
for implementing a non-SQL ORM.

[John Siracusa]

2009/11/18 Ted Zlatanov <t...@lifelogs.com>:

> I wonder if RDBO can use a non-relational database: Amazon SimpleDB,
> Cassandra, HBase, CouchDB, etc.

Not likely unless someone writes a DBD:: driver for it. RDBO only
works with DBI data sources. It expects to connect with DBI, call DBI
methods, and pass SQL to them. This is not likely to change.

-John

[Ted Zlatanov]

On Wed, 18 Nov 2009 14:18:39 -0500 John Siracusa <sira...@gmail.com> wrote:

JS> 2009/11/18 Ted Zlatanov <t...@lifelogs.com>:

>> I wonder if RDBO can use a non-relational database: Amazon SimpleDB,
>> Cassandra, HBase, CouchDB, etc.

JS> Not likely unless someone writes a DBD:: driver for it. RDBO only
JS> works with DBI data sources. It expects to connect with DBI, call DBI
JS> methods, and pass SQL to them. This is not likely to change.

Have you or anyone else used it with DBD::DBM? That seems like a good
example of a limited SQL layer on top of a fundamentally non-relational
storage backend, and I can implement something similar for Cassandra at
least. So I guess I need to know what is the minimum SQL support RDBO
needs from the DBI driver.

Ted

[John Siracusa]

2009/11/18 Ted Zlatanov <t...@lifelogs.com>:

> Have you or anyone else used it with DBD::DBM?  That seems like a good
> example of a limited SQL layer on top of a fundamentally non-relational
> storage backend, and I can implement something similar for Cassandra at
> least.  So I guess I need to know what is the minimum SQL support RDBO
> needs from the DBI driver.

RDBO will generate basic INSERT, UPDATE, and DELETE statements, plus
JOIN, LEFT OUTER JOIN, and nested versions of same, with LIMIT and
ORDER BY clauses. In the areas where the supported databases diverge
a bit in syntax (e.g., LIMIT clauses) there are existing hooks into
the db-specific Rose::DB subclasses to handle that. But most of the
SQL generation stuff is common.

If you want to do the introspection stuff, you'd need to support all
of DBI's table_info/column_info stuff, plus implement your own unique
key lookup code.

-John

[Darren Duncan]

In the future, when it works, my Muldis Rosetta project should help RDBO do just
that, as its DBMS API is more expressive than SQL+DBI but can easily map to the
latter. Helping users take advantage of SQL's strengths while helping mitigate
SQL's limitations is part of its goal. On the other hand, its native API is
still squarely in the relational model, so you would still have to map any
non-relational DBMS concepts to relational ones, but just more elegantly than
with SQL. -- Darren Duncan

[Ted Zlatanov]

On Wed, 18 Nov 2009 11:05:33 -0800 (PST) Peter Karman <pek...@gmail.com> wrote:

PK> So I wouldn't recommend trying to retrofit non-SQL DB support into the
PK> RDBO infrastructure, but I *can* recommend Rose::Object as a good OO
PK> framework (the other being Moose) and RDBO as a good design pattern
PK> for implementing a non-SQL ORM.

I don't think RDBO is a good fit for what I proposed, which is not an
ORM at all. For example, the databases I listed allow you to add and
delete columns at will, while RDBO has a very static view of what
columns are available.

I'm not sure if Rose::Object would work. Moose annoys me, it's
extremely slow with large data sets and requires half of CPAN.
Something JSON-like in the way it loads and stores data would be most
appropriate, I think.

I'll investigate this further and report back, thanks to everyone for
the suggestions.

Ted