On 6/13/02 1:29 PM, Perrin Harkins wrote:
> Just be careful that you don't end up making this into something that
> mirrors the SQL exactly. There might be 4 tables involved in finding
> out what kind of credit card the user had, but that gets hidden behind
> this API. If you find yourself writing classes that take options like
> "where => 'date > ' . $date" you are reinventing SQL, and you've lost
> your abstraction.
"Stringy" stuff like that is certainly a poor abstraction (or no abstraction
at all if it's stuck directly into the SQL!) But I've done stuff like this:
Pets->get_pets(type => [ 'dog', 'cat' ],
age => { and => { gt => 5, lt => 10 } },
name => { match => 'Fi.*' });
which is powerful enough to do most types of basic selects, but still
abstract enough that the user of this class never actually types SQL
fragments directly.
Of course, the case above is a rarity. Usually, it'll be used in the simple
form like:
Pets->get_pets(type => 'dog', age => 5);
But just having that more complex form in there for the one or two times you
need it is sometimes valuable, IMO. And the overhead is minimal if you have
a nice base class that supports all this stuff for you.
-John
