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 ?
In reply to Re: Subclassing DBI instead of wrapping
by renodino
in thread Subclassing DBI instead of wrapping
by spq
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |