Re: elegent way to handle "pluggable" backend servers?
From: Jon Lapham (lapham_at_jandr.org)
Date: 02/19/05
- Next message: Bill Costa: "Using Oracle's Perl tree instead of OS supplied distribution..."
- Previous message: Michael A Chase tech: "Re: Curretn DBD for Oracle"
- In reply to: Brian D Campbell: "RE: elegent way to handle "pluggable" backend servers?"
- Next in thread: Steven Lembark: "Re: elegent way to handle "pluggable" backend servers?"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Sat, 19 Feb 2005 11:23:10 -0200 To: "CAMPBELL, BRIAN D (BRIAN)" <campbelb@lucent.com>
CAMPBELL, BRIAN D (BRIAN) wrote:
> I suggest that you want an OO approach and encapsulate the driver
> differences in several "subclasses". I'll assume you know how to do
> OO in Perl (i.e., create OO classes and methods with modules and
> subs).
Hmmm, that is an interesting idea.
> Near the beginning of your Perl program, you'll do a one time
> if/elsif to assign the driver/version object (we'll call it $d).
>
> if ($dbserver eq 'MySQL' and $dbversion == 3.23) {$d =
> Mysql_3_23::new()} elsif ($dbserver eq 'PgSQL' and $dbversion == 7.4)
> {$d = Pgsql_7_4::new()} elsif (etc...)
>
> At all locations in your code, where there is a driver difference,
> factor that out into the subclass. So far this sounds a bit like
> your second suggestion, but let me suggest that you don't do:
>
> $SQL = $d->some_query();
> $result = $conn->prepare($SQL);
> $result->execute();
>
> But rather factor out the minimal amount that truly relates to
> differences in your database and driver, and not your domain. In
> other words...
>
> $SQL = 'SELECT * FROM blah WHERE ' . $d->Boolean('active');
> $result = $conn->prepare($SQL);
> $result->execute();
>
> In this example, Boolean is a method that all subclasses implement
> and returns the appropriate Boolean syntax for the given column name.
Yes, I see what you mean. This works great for the boolean case.
My concern would be that some of the differences in database backend
capabilities (ie: subqueries, cascade on delete, etc) actually force the
entire SQL statement to be re-written, or (worse) to become multiple SQL
statements. Unfortunately, sometimes it is not just as simple as the
BOOLEAN case I used in my example.
I probably should have used a subquery example in my original email. :)
> Where ever you have commonality between several subclasses, you can
> factor the common functionality into a base class that they share.
> With the number of subclasses you are talking about, and I can guess
> at their nature, I'd venture that you could create quite an
> inheritance tree, depending on the mix of common and different
> behaviors in your databases. But that's OK.
Yes, this would be great. The ability for a new backend-version to
inherit most of the SQL from a common class would be very powerful, and
save a lot of time in writing the new subclass.
Thanks for the ideas, I need to mull...
-Jon
-- -**-*-*---*-*---*-*---*-----*-*-----*---*-*---*-----*-----*-*-----*--- Jon Lapham <lapham@jandr.org> Rio de Janeiro, Brasil Personal: http://www.jandr.org/ ***-*--*----*-------*------------*--------------------*---------------
- Next message: Bill Costa: "Using Oracle's Perl tree instead of OS supplied distribution..."
- Previous message: Michael A Chase tech: "Re: Curretn DBD for Oracle"
- In reply to: Brian D Campbell: "RE: elegent way to handle "pluggable" backend servers?"
- Next in thread: Steven Lembark: "Re: elegent way to handle "pluggable" backend servers?"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
