Re: Subclassing DBI instead of wrapping

While I disagree with earlier assertions wrt the difficulty in subclassing DBI (except possibly for some conceptual challenges), you haven't really presented what your purpose is other than "adding a few methods".

Where I've found subclassing useful is for extending SQL, rather than the DBI API (e.g., DBIx::Chart). Similarly, it might be useful for applying filters for calls to the existing API (e.g., scrubbing parameters and/or results, implementing a federated database abstraction, etc.). However, it isn't amenable to some things (e.g., DBIx::Threaded required an entire wrapper, even tho it was just implementing the same API)

I think the dividing line may be "extending DBI so any existing DBI app can use it" vs. adding new APIs to DBI...the latter will likely require apps to make non-trivial changes anyway, so the ROI of subclassing may not be that great.

However... if O-R wrapper authors accomodated DBI subclass support, then it might be worth the effort of subclassing, and perhaps reconsidering your enhancement as a SQL syntax filter or do()/prepare()/execute() attributes addition ?

Comment on Re: Subclassing DBI instead of wrapping

Replies are listed 'Best First'.
Re^2: Subclassing DBI instead of wrapping by spq (Friar) on Aug 23, 2006 at 02:14 UTC
What I mean by "adding a few methods" is really just laziness. And in all cases I've done this it was for very topic-specific environments. For example, one use I've made is at a bioinformatics center where we have a database of genomic information. While many projects will have their own databases, there are certain very common requests which might be made from the public databases. For instance, getting all the peptide sequences for a list of given ids. While it's a simple enough SQL statement to write, it is used so often I wanted to provide an easier way to accomplish this frequent task. Originally I had a module which had a dozen or so similar shortcuts that took a database handle as one of the arguments (this also insulated the database design allowing me to improve and extend the schema with vastly less code breakage). However I also noticed I was pasting the same connection method in most of my code (same database, server, username, etc) and so I added a method to connect to that module. I'd barely done coding that and changing some programs to use it before it occurred to me that calling a function in my module to connect to the database, then handing that connection right back to other functions in the module was a bit of a waste of time. So, I sorted out how to use AUTOLOAD (this was going on 6 years ago) and instead just wrapped the DBI. This made a lot of things much simpler; any code using my module could use the database handle returned just as normal, but they also got a small collection of simple, stable short-cuts for doing some very common tasks. I've found the template so useful I have reused it in a number of other similar projects. Nothing fancy, and as I said, nothing whatsoever that interferes with how any of DBI's built-in methods work.	[reply]

Replies are listed 'Best First'.

Re^2: Subclassing DBI instead of wrapping
by spq (Friar) on Aug 23, 2006 at 02:14 UTC

What I mean by "adding a few methods" is really just laziness. And in all cases I've done this it was for very topic-specific environments. For example, one use I've made is at a bioinformatics center where we have a database of genomic information. While many projects will have their own databases, there are certain very common requests which might be made from the public databases. For instance, getting all the peptide sequences for a list of given ids. While it's a simple enough SQL statement to write, it is used so often I wanted to provide an easier way to accomplish this frequent task. Originally I had a module which had a dozen or so similar shortcuts that took a database handle as one of the arguments (this also insulated the database design allowing me to improve and extend the schema with vastly less code breakage). However I also noticed I was pasting the same connection method in most of my code (same database, server, username, etc) and so I added a method to connect to that module. I'd barely done coding that and changing some programs to use it before it occurred to me that calling a function in my module to connect to the database, then handing that connection right back to other functions in the module was a bit of a waste of time.

So, I sorted out how to use AUTOLOAD (this was going on 6 years ago) and instead just wrapped the DBI. This made a lot of things much simpler; any code using my module could use the database handle returned just as normal, but they also got a small collection of simple, stable short-cuts for doing some very common tasks. I've found the template so useful I have reused it in a number of other similar projects. Nothing fancy, and as I said, nothing whatsoever that interferes with how any of DBI's built-in methods work.

[reply]