byterock

So spent a little time working on my rough code from my last post and made up a working copy that you can have a look at here.

It was easy enough to get the SQL part working, after all I have been using such code my Data Accessor for many years now. It also took only a few minutes create a new DA::Mongo class with and an '_execute' function to come up with the query for Mongo.

With my limited test I get the correct query in SQL

 

SELECT street, city, country FROM person  AS me 

and Mongo as well

 

db.person.find({},{ street: 1, city: 1, country: 1}

So I have accomplished one of my goals; To have the same set of params to my API come up with the correct query in either SQL or Mongo.

Now this is all great and good but my code has started to diverge even with this very simple use case.

Now I did expect the '_execute' sub to change for every version of my Accessors but what is really a concern to me are call like this one in the SQL version

 

$self->view()->sql();

Where I am using the 'SQL' sub native to the DA::View object but in the DA::Mongo code

 

$self->view()->name();

I do not use that SQL sub I just use the name attribute. Had I used this SQL sub in DA::Mongo I wold of come up with this

 

db.person as me .find({},{ street: 1, city: 1, country: 1}

Which is just dead wrong, as there is no real concept of a table alias in MongoDB, so right away I have an orphan sub in the DA::View and DA::Element when working with a MongoDB. I would really be causing problems for uses it I left this situation to continue.

Now I do know there are some kludges in MongoDB to create alias for elements but it is never a good idea to use non-standard code in an API so that is a non-starter as I would be breakink so many rules.

So that SQL sub will have to change in my next iteration as both what it does and its name are only correct for the DA::SQL class, so out of DA::View and DA::Element it comes.

My other goal, to pass a connector and let my Data Accessor figure out what to do, has not even been looked at yet and it looks a little tricky.

So I am going to have to put my thinking cap on and come up with some ideas.