byterock

Now onto another problem!

With present Perl version of my Data Accessor I had only a very small set of common methods, the CRUD ones and add_dynamic_criterion while the DA::SQL brought into the API many methods and attributes that are SQL specific.

• Table
• Fields
• Group_by
• Where
• Having
• ...

So if one of my evil plans is to make DA work across a number of differing DB platforms it would not be a good thing if for each of the accessor drivers would have its own API. Could also see the case where drivers for the same sort of DB say Mongo and Clusterpoint could have completely different APIs.

This would be no problem for the end user (remember her out on the pointy end writing up REST ful web services and desktop apps) as they would just have that nice little CRUD API to play with.

The programmer who will really suffer are the ones writing up those instance classes they may have to learn two maybe three new APIs not something you would want. Myself, I would just drop the new APIs and go back to the native SQL for DBI operations.

So I am going to abstract the second layer of my API and try to enforce some commonality in the API for Data Access instances.

Funny thing is I did a few searches for abstracting SQL and alike and came up with stuff like this;

which is suppose to be an 'abstracted' version of this SQL statement

SELECT a1,a2,.... FROM t WHERE c;

I guess it proves either that I am not a mathematician or that I do not know what abstraction means because to me this more like obfuscation.

Undaunted by this I have come up with a simplified model to build my API on;

Param
As the name suggests a placeholder for data supplied by the programmer to pass to the target database

Element
A name value pair, aggregate, or expression that Data Accessor will use to map to the target database.

Predicate
A logic statement consisting of a left and right Element or Param with a logical operator between that is used by Data accessor to map logic operations on the target database.

View
A collection of Elements that Data Accessor will use to map to the target database

Condition
A logical Predicate supplied to the target database by the Data Accessor to filter data.

Link
A logical predicate supplied to the target database by the Data Accessor to link or join data.

Gather
An element to be use in aggregation operations supplied to the target database by Data Accessor.

Filter
A logical predicate used to filter Gather operations supplied to the target database by Data Accessor

Sort
An element or expression supplied to the target database by the Data Accessor for sort operations

Now that covers all of the basics and the table below shows the SQL and Mongo equivalents

+-------------------+-----------------+-----------------+
| Data Accessor     |  SQL            | Mongo           |
+-------------------+-----------------+-----------------+
| Param             | Param           | Param           |
| Element           | Field           | Name Value Pair |
| Predicate         | Predicate       | Options         |
| View              | Table (or view) | Collection      |
| Link              | Join            | Lookup          |
| Gather            | Group           | Aggregate       |
| Filter            | Where           | Find            |
| Sort              | Order           | Sort            |
+-------------------+-----------------+-----------------+

At least it is a start.