byterock

It is cheap clip show day here in the Moose-Pen

Now that I am finally finished with Database::Accessor for the moment as since my last post all my tests are passing, I think it is time for a quick recap of what when on since this post when I left the Dist-Pen and started up the Moose-Pen.

The first few post I set out on writing my first Driver::DAD, I worked out some name-space issues and finally came up with Database::Accessor::Driver::DBI rather than SQL as most DBI drivers run on SQL is just seemed locgial.

The second set of posts I started to write up my Driver::DBI and ran into the problem very quickly that I needed some sort of DBI DB present on the current box to do any testing. I solved this as 'DBD::DBM::db' comes with DBI so I decided to use that for my testing. I even got one or two test cases written and a little code done.

I quickly ran into a road block with Database::Accessor. No way to see the DAD and get the query and check to see it it is correct. This lead me down my next set of posts where where I stated the very slow re-factoring of Database::Accessor.

I introduced two new Moose plugins, MooseX::Privacy to make a few of my 'subs' internal only and 'MooseX::Attribute::ENV' as a way to enable debugging without having to change a program.

I also created a new 'Results' class to capture and return the results from the call out to DBI.

I think most importantly I opted to adopt the strategy of putting as many of the query 'Rules' in the Accessor.pm rather than letting the DAD Driver writer work them out. The 'Rules' in this case are the database independent ones such as disabling an Element' for update or a 'Gather' only being allowed on a 'retrieve'

So right now I am making a promise to my DAD writers that Database::Accessor will only pass down what is needed for the present action.

So no code today but here is a cute baby moose pic,