I have to disagree with you. He specificaly mentioned why he made his own over useing an existing one and I think thats great. I've looked at the abstraction modules before and most of them add more complexity than just writing your own SQL. Looking in the DBIx category I see only two other modules that seem to fit this category. DBIx::Abstract and DBIx::Simple (which actualy uses DBIx::Abstract. Does DBIx::Handy provide the some overlapping functionality with DBIx::Abstract? Yep. Does being the current Abstraction module makd DBIx::Abstract the one and only needed module? That's just ridiculous. I think this is a nice simple module that doesn't have all the complexity those do. When you want abstraction you want to just be able to pass it a hashref and move on. This lets you do that while others do not. This constant concept that because there is already a solution aviable a second shouldn't be created is completely contrary to the concept of DWIM and TIMTOWTDI.
BTW I think the name should be changed to something that has meaning at a glance. When I think 'handy' i think some extra tools for a job that will be handy. In your case then I would expect update and insert to take a DBH, table name and hashref. Then its just a handy tool to do inserts. I would still add abstract to the name. DBIx::SimpleAbstraction or DBIx::Abstract::Simple even.
Update: fixed borked links
Update: DBIx::Simple actualy uses SQL::Abstract not DBIx::Abstract. /me heads off to look at all the SQL modules. ;) Thanks Juerd for pointing that out.
In reply to Re^2: RFC DBIx::Handy
by eric256
in thread RFC DBIx::Handy
by techcode
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |