SPUG: Runtime binding, drivers
chris at chriskate.net
Thu Oct 10 18:20:36 CDT 2002
I'll throw my 2 cents in on this, at least in how DBI/DBD stuff works
and my experiences.
At work we run MySQL and Postgresql. No matter how hard you try and make
things common to work with both databases, by using the DBI interface,
there are aways exceptions in the underlying way the two different
At some point do you just give up on the "middleware" DBI code and just
use the direct "Pg" or "MySQL" perl interfaces, especially if you are not
likely to have different databases. As much as people like to say "this
complicated code base can work with Postgresql, Oracle, DB2 or whatever,
all you have to do us use DBI", there are times when the implementation
just doesn't work out and is not the most efficient way to do things. (As
an aside, Postgresql and MySQL are way different types of database.
Don't let anyone tell you any different).
In your Dog/Cat example below, might there be a very special unique type
of Cat which can't speak and which would not work with that interface.
I guess what I'm getting at is at some point, you need to decide when the
"middleware" has gotten more complicated than its worth and you are better
off just learning how to bark and meow ;)
On Thu, 10 Oct 2002, Trevor Leffler wrote:
> Brian Ingerson wrote:
> > On 08/10/02 17:26 -0700, Trevor Leffler wrote:
> >>Hi all,
> >>I've been researching the implementation of "drivers" in Perl, and am looking
> > What type of drivers are you talking about? You can't do kernel loaded
> > drivers in Perl by definition. Perl is linked with the libc, and those system
> > calls can't be made from kernel code, AFAIK.
> > Cheers, Brian
> I am not talking about hardware drivers or other low-level kernel nastiness.
> Sorry if I scared people off with that terminology! Rather, I'm am interested
> in DBI/DBD-style drivers. Or perhaps I should call them "implementations
> conforming to a defined interface." Perhaps some tangible, if silly, code would
> help show my thoughts.
> my $dog = new Animal("Animal::Dog");
> my $cat = new Animal("Animal::Cat");
> $dog->speak("Fork over your bacon!");
> # Output: "Woof! Fork over your bacon! Woof!"
> $cat->speak("Don't rub my fur the wrong way.");
> # Output: "Meow! Don't rub my fur the wrong way. Meow!"
> Think about how DBI works here. We ask for two animals, a dog and a cat, both
> of which conform to the Animal interface (one method, "speak", which takes a
> string). Our $dog is actually an Animal::Dog object (not an Animal object),
> which implements the interface in its own special way--it prepends and appends
> "Woof!" to the passed string. Likewise, our $cat is an Animal::Cat object.
> The implementation might be in pure Perl, or XS, or whatever. The point, and my
> queries, are about the architecture that could make this possible. Do I look to
> DBI as a model (ugh) or are there other models to follow? I keep bringing up
> DBI only because I'm unaware of other Perl modules that do what it does.
> BTW, I've already coded something that works, but I'm really interested in some
> discussion of this topic--your experience with this, pros and cons of model A vs
> model B, if you have no experience with this then what do you think it *should*
> do or behave. How would you design it?
> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
> POST TO: spug-list at pm.org PROBLEMS: owner-spug-list at pm.org
> Subscriptions; Email to majordomo at pm.org: ACTION LIST EMAIL
> Replace ACTION by subscribe or unsubscribe, EMAIL by your Email-address
> For daily traffic, use spug-list for LIST ; for weekly, spug-list-digest
> Seattle Perl Users Group (SPUG) Home Page: http://seattleperl.org
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
POST TO: spug-list at pm.org PROBLEMS: owner-spug-list at pm.org
Subscriptions; Email to majordomo at pm.org: ACTION LIST EMAIL
Replace ACTION by subscribe or unsubscribe, EMAIL by your Email-address
For daily traffic, use spug-list for LIST ; for weekly, spug-list-digest
Seattle Perl Users Group (SPUG) Home Page: http://seattleperl.org
More information about the spug-list