byterock

So I have sketched out my test suite lets have a look at the API I am trying to express.

For me the API is the most important part design. Have a good workable general purpose one it will become a de-facto standard, like DBI, do a very narrow one it will languish in the niche that is was designed for. It has been said many times before, but it bears repeating here, that any API should be

• Easy to Learn
• Easy to Use
• Easy to Extend
• Consistent and
• Hard to misuse

Well on the higher level my Data Accessor will be easy to use with just the basic four CRUD operations so that should be easy to use and learn.

Looking at the next layer the SQL.pm side I can see I have some work to do. There are some dozen functions to just add in joins, down by the way from thirty six in the original JAVA, and three different ways to clear out results and that is just two examples I could add a few more.

Suddenly when one gets down to the next layer the API becomes much more complex. If I go into the function level detail and look at 'add_condition' it has four calling signatures, I can see that might be irksome to some. This is just the tip of the ice-berg many of the other functions in SQL.pm have multiple calling signatures a carry over form the original JAVA but in an untyped language like perl this is problematic. Well at least the top layer is clean.

With all the above my second layer is anything but consistent, easy to learn and use. It takes quite a bit of practice to get all little bits working correctly so the easy top layer is exposed. Not the situation I want.

On the plus side there where some safeguards built into the system such as 'can_global_delete' which defaults to false so one always needs a 'condition' when doing a delete. As well the system extensively users parameter validators, a perl attempt to carry over JAVA's strict typing I guess. There are some forty of them which just adds to the complexity of the code.

As I have stated before there is the odd bit of Oracle specific code sprinkled in there as well, never a good thing if you want to make a system DB agnostic

With the present code I found that my instance level code was tricky to work with, as the API is in a shambles while the higher level the API was quite easy to use. This is fine for something like a DBD as you only write one of those I can't really see coders doing that for Data Accessor for each new project.

At the present time my Data Accessor can be easily extended to cover more Data sources as it only call for the calling class to implement an '_execute' sub that will process the throughput from the high level DA.pm

One problem I see is there is a great deal of sub bleed from the lower level SQL.pm code up into the DA.pm code greatly expanding the top level API unexpectedly which is typical of system where the lower order code extends against the higher level code. Will have to drop that.

So the potential is there but I really have some work to do.