Re: OO Architecture

On Wed, Sep 28, 2005 at 11:40:12AM +0200, Honza Pazdziora wrote:
> 
> I'd say that subclassing the DBI is not important at all ... if there
> is some other way to achieve my goals (traditionally done by
> subclassing).
> 
> What are the goals? To me, it is modification of certain aspects of
> DBI's behaviour. Maybe you want some pre-preparsing or modification
> of you statements (I have DBIx::ShowCaller on CPAN that adds a comment
> line with the Perl caller information so that I can find it in Oracle
> cache and see who sent me that query). Maybe you want different logging
> support (I have a module that catches errors in production environment
> (where no errors should happen so if they occur, it's really fatal)
> and sends the error via email). Maybe you'd like charset conversion
> to be done automatically but the usage to specific to bother
> Tim with adding it into DBI core. Plus: maybe you want all three of
> these at the same time and you want to keep you code tidy -- to have
> three modules of which each provides single modification and which can
> be used together or one at a time.

(That scenario matches the pick-n-mix merging of roles I mentioned in
my recent post.)

> IIRC (but the last time I did DBI subclassing was like five years ago,
> so the interface might have changed -- sorry Tim, if I'm missing
> something) subclassing is done by setting RootClass. That's nice, but
> how do you do multiple inheritance? One module modifying your parsing,
> another one modifying your logging behaviour ... Currently you have to
> create a single module that combines both behaviours, don't you?

Yes for DBI v1. For v2 goal 9 comes into play:

  9. Define the DBI and drivers in terms of multiple interfaces to simplify
     reuse or replacement of components.

I'll pad that out a bit more but basically things like pre-processing
sql, logging, error handling etc., will all be separate classes and a
handle will have objects of each that it'll call methods on as needed.

So it'll be much easier to switch to alternate implementations of
individual components (or subclasses of the default components :).

> I'd like to be able to say that a particular DBI->connect call should
> give me vanilla DBI behaviour plus modifications specified by
> DBIx::Module1, DBIx::Module2 and MySite::Module3. Where maybe
> DBIx::Module2 modifies behaviour or DBI::connect itself.
> I'd like to be able to plug in MySite::Module4 to existing $dbh, do
> a couple of operations and maybe remove it later from the stack.
> 
> Is it callbacks I'm talking about? Handlers in Apache?

Different techniques will best suit different situations.

> Being able to do something before, after and instead of a particular
> DBI call.

Subclassing gives you that.

Adding pre and post callbacks would as well, but I probably won't add
those unless we go with a HAS-A and method redispatching (like DBI v1)
since that's the only way to make it practical.

> Being able to specify it either via class name, or using
> individual references to subroutines that will be provided with
> well-defined sets of parameters and will signal the result down the stack.

That's sounding more like chains of handlers, ala Apache.
That's unlikely to be in the core, but a subclass could implement it :)
I've just added a new goal:

 15. Keep the core DBI as small and simple as possible, but no simpler.
     If it can be done outside the core then it probably should.

> If I'm later going to make a subclass, by naming those changes
> and putting them into a single module is just a nice final touch. But
> in many cases, you actually do not need and do not want to subclass.
> You just want a slightly different behaviour.

Can I restate that as: You just want a slightly different behaviour but
don't really care much how it's done so long as it's reasonably simple.

(Anyone want to take on the task of listing all the "slightly different
behaviours" that people here and on dbi-users can thing of?)

> Hmmm. Did I get off-topic / miss what the subclassing business was all
> about in the first place?

No, you're exactly on topic. Thanks.

Tim.