byterock

Now that I am getting further from my Java story and closer to a Perl story, which is good me thinks, I am going to pause and ask myself a few questions, before I jump into the rebuilding my DataAccessor aka DBIx::DA.

1. Isn't this just re-factoring/re-design for re-factoring/re-design sake?


2. What is the end use of this new module?


3. Hasn't this already been done to death?


4. Isn't this just going to pollute the name-space?


5. Is there even a business case for this code?

Though questions for a one page blog but here we go with the 25c answers

Isn't this just re-factoring/re-design for re-factoring/re-design sake?

No it is not. Here is one good code reason why I am taking this on.

 

use base qw(DBIx::DA Exporter); 

When the first version of the code was written 'use base' did only two little things;

1. require the module
2. add it to the @ISA.

Now from what I read'use base' does much more and I am not sure it still does what I thinks it did. Recently in another project, with up to date Perl, I noticed that this little Pragmata caused me all sorts of trouble. I ended up with the same instance data on all of my classes that had the same ancestor, going to have to a post on that one day but that is another story. So given the trouble that it cause me I think it is reason enough for the rebuild. As well the only version was never made SQL agnostic an important factor in what I want to use it for.

What is the end use of this new module?

Well as the name says it all. Data Access. At the present time I am working on a project where the data presented to the end user, the abstract if you will, comes from from both a RDBS and a Key-Store DB. So having one common interface for both ie

 
   $keystore->update({address=>'xxx'...})
   $rdbms->update({address=>'xxx'...})

would come in handy. The DA code doesn't do this right now so it would be new functionality, as well there is no set RDBS for the new product so it should be SQL agnostic as well.

Hasn't this already been done to death?

Well, if you think of DBIx::DA as an ORM then yes, but if you are thinking this, you would be wrong. It has never had nor will it have any meta data about the DB, so it does not know that that X is a varchar(250) and it is related to Y or when you delete P you also delete Q. So you might say 'what is the point of it?' if are able to to create nonsense SQL with it. Well that might be true, but it also true of a phone dial. Just because you can enter a wrong number it dose not stop it from being useful.

I have looked for similar mods on CPAN but have not found one yet though DBIx::Easy is somewhat similar so maybe there really is a need.

Isn't this just going to pollute the name-space?

Well looking at the initial name I came up with 'DBIx::DA'. I would say yes it will pollute the name-space. This is simply because it does not extend DBI in any meaningful way. If you take DBIx::Pager for example you get new functionality i.e.

 
    print  $pager->page_count();

giving you something you did not have before.

It dose wrap some code like DBIx::Wrapper but not everything so you are loosing out on functionality. Finally if I plan to use this to access to a key-store DB then I most likely will not be using DBI at all. So,

 
   use DBIx::DA::Mongo;

Will anoy many, confuse some and really break the name-space as there will most likely will be no DBI code in that part. Unless someone writes a DBD::Mongo??

In the end I was just badly mistaken when I first put it under the DBIx name-space, name space envy I guess, some 10 years ago. So I will have to just suck it in like DBIx::Abstract did and find a better name-space for it.

Is there even a business case for this code?

Well for me yes and not just because I like to code. For anyone else it will fit in whereever you need well typed DB agnostic data access layer for your abstraction layer. This may sound a little redundant having what is in essance two layers of abstraction, but I do know of a few enterprise level DBIx::Class users that do just this this, an abstract class around DBIx::Class. For them it is a distinct advantage as they have a large number of teams that work almost exclusively on one part of an even larger Data Base. Simply put it makes it much harder for the differing teams to step on each others toes. Also fits in well where there is a need to be both DB and Query language agnostic.

So that is most of my questions looked at. Maybe I will get started soon.