SPUG: Runtime binding, drivers

[Trevor Leffler]

So you'd say that in practice, DBI doesn't really live up to the hype of "Don't 
change a line of code!  One DB interface uber alles!"  Is this a failing of DBI, 
and if you were to redesign the API, could you fix it?  Rather, it sounds like 
what you're saying is that, yes, these two things are DBs, but they are so 
dissimilar that no API could be designed to unify to two.

How about this... Regarding the issue of a service's (filesystem, DB, animal) 
capabilities, would it satisfy you if your app could query the service's 
capababilities and then "do the right thing?"  For example, we decide that the 
Animal API should not require a method "speak," because we know that 
Animal::Fish can't.  How about adding "speak" to some optional capabilities list 
that our app could query for.  Perhaps your app could also ask for all the 
implementations that can speak.

Since the middleware is still be designed and I get to test it out, I hope to 
inform the designers about issues like these--it's too dumb! it's too complex! 
it doesn't work with product X!

Thanks for your input.  I'll keep it in mind as I apply this stuff to real-world 
situations.

Thanks,
--Trevor

Chris Sutton wrote:
> 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 
> databases behave.
> 
> 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?
>>
>>Thanks,
>>--Trevor


 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
     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