And the Plot Thickens

Yesterday I looked at maybe abstracting my API to make it common across a number of Data Accessor Derivers such as SQL and MongoDB and that got me thinking of how I am going to put all the pieces together?

Now what I would like is the end user to be able to something like this

my $address_da = SomeDa::Address()->new();
my $address_hash = {};
my $dbh = DBI->connect(“DBD::aything”,$uid,$ps);
print $address->{steet}...

The present way I do things with Data Accessor, that 'SomeDA::Address' had to be an instance or extension of my DA::SQL class as shown here. Now do I have to do it this way? What if I made may Data Accessor smart enough that it could tell by the Connection you are passing what Driver to use so my SomeDA::Address could work with MongoDB as well. Like this


An interesting concept. Let me just model out the good old Person with Address first in RDBMS format


and now on mongo


now how about expressing this in API language from my last post but in a hash so we can at least code with it

view => 'person',
elements => ['name','street','country','city']

now that works fine for both Mongo and SQL but that is a piss poor table and document design. So how about better models like these

so in my little API is not going to cover the above without adding a little more into my Elements like this

view =>'person',
elements =>[{name=>'name'},

Now that will work fine on Mongo as the 'address' document is in the 'preson' document but this need to be expanded again for SQL as I have to join the two somehow. I could just do the good old explict join in the back end assuming the DB can do that and the DBA named his fields with some sort of sanity but that can be a longshot.

So lets for now add in the join

view => 'person',
elements => [
{ name => 'name' },
name => 'street',
view => 'address'
{ name => 'country',
view => 'address' },
name => 'city',
view => 'address'
link => {
to => 'address',
on => { name => id },
{ name => address_id }

and that covers off the SQL part, making some assumptions of course; on the type of join that is to be done on the SQL side and that the MonogDB does not need the link or join in this case, but it is a start.

Leave a comment

About byterock

user-pic Long time Perl guy, a few CPAN mods allot of work on DBD::Oracle and a few YAPC presentations