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.

They're actually mostly under SQL::, not DBIx::. For example, SQL::Abstract, SQL::Generator, and SQL::Interpolate.

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.

This idea that duplicating existing modules is somehow more "DWIM" doesn't make much sense to me. Ask someone who searched for "template" on CPAN recently whether they think everyone who wrote their own module without checking CPAN carefully should upload it. TMTOWTDI is not a universally good thing.

I'm not in favor of any sort of strict control over what gets uploaded to CPAN, but when someone asks for comments, and I think their module is a dupe, I'm not going to encourage them to upload it.

Yeah Handy doesn't say much - I agree that it should be changed to something more meaningful.

I also agree that TMTOWTDI is not universally good thing - it's actually brought up as a bad side of Perl when it's compared to other languages (they say code is harder to be maintained but I say it's all about coding standards and style).

I was looking into those abstraction modules and as pointed out they were either overkill with complexity or simply didn't do what I wanted - so I implemented that on my own (some point out they are slow too). I've recently faced a problem of needing to pass around my initial DBH so I added that to the module too - then I realised that my project needs more than one DB connection, so I'm slowly adding that too.

I have no idea where it will end - but at this stage I also don't think that it's even near to get on CPAN.

If nothing else - it's great experience :)

Ahh I didn't look in SQL:: ... frankly I didn't even know there was a SQL::. In that case I would have to re research. Our disagreement then is still over weather it is a duplicate or not and weather this adds to DWIM or not. For me the abundance of Template modules lets me pick and choose. I use two different CPAN templating modules and one of my own concoction depending on what I need to do. Thats why I mentioned DWIM. " TMTOWTDI is not a universally good thing." I would disagree because giving more than one option means that you are more likly to fit the one that fits your need. I would say that most of the options on CPAN need better explanations of how they differ though.

"but when someone asks for comments." Certainly understood, I just wanted to OP to see an opposing view. Wether he uploads it or not I wanted to make it clear some of use say yay while others say nay and hopefully provide him with some arguments both ways. I didn't mean to imply in anyway that you shouldn't have posted or even that you shouldn't have said what you did. I simply wanted to say I didn't agree and why.


___________
Eric Hodges

DBIx::Simple (which actualy uses DBIx::Abstract.

That's not true. DBIx::Simple uses SQL::Abstract, not DBIx::Abstract. See DESCRIPTION in SQL::Abstract's documentation for an overview of the most important differences.

Juerd # { site => 'juerd.nl', plp_site => 'plp.juerd.nl', do_not_use => 'spamtrap' }