mbethke has asked for the wisdom of the Perl Monks concerning the following question:
There's heaps of database abstraction modules in Perl but it seems that while abstraction always means "You don't have to deal with messy C interfaces", and sometimes "You can write SQL in Perl", it hardly ever means "we'll take care of data type idiosyncrasies for you". I need something like that.
My problem (briefly mentioned in my announcement of Ashafix) is this: I've used a couple of DBMS layers but all programs have been tied to one particular DBMS. Now I want to write one that runs unchanged on at least PostgreSQL and MySQL and my first problem is the handling of booleans. Pg uses an own type that returns 't' or 'f' while MySQL by convention uses TINYINT that is set to zero or non-zero. Currently I'm using DBIx::Simple and I'd prefer to keep it fairly slim. My ideas so far:
- Define an ENUM in MySQL to emulate the Pg behavior. Doesn't work because other software is using the database too and would get very confused.
- Use DBIx::Class, write my own InflateColumn::Bool and a primitive Bool class that uses a tied hash or something to give the usual zero-or-nonzero-scalar behavior when used in boolean context.
Disadvantage: that's about as fat as it gets. - Subclass DBIx::Simple, feed it a simple column=>type mapping for each table I'll use and make all retrieval methods use a hash()/hashes() method internally so I can do the mapping myself.
Disadvantage: smells inefficient (although it's probably still much faster than DBIx::Class), may be reinventing the wheel.
Have I by any chance overlooked something on CPAN that would let me do this in a simpler way?