There would therefore often be a call chain like this:
APPLICATION | DBI instance #1 | DBD::MyFooModule | DBI instance #2 | DBD::NormalDbDriver | DATABASE
My question is this:
1. Is it reasonable for a DBD module to create and invoke other DBI instances that are distinct from the one that invoked it?
2. Do any existing DBD modules do this successfully?
3. Are there any global variables or settings created or used by DBI that would prevent the above two DBI instances as acting like they were complete separate and independent? Could the APPLICATION do something with DBI instance #2 that could change DBI instance #1 and mess up DBD::MyFooModule?
4. Do I have any reasons to be concerned, or should what I'm looking at just work, aside from bugs in my own code?
Thank you. -- Darren Duncan
Have you consider just subclassing the DBI ? E.g., assuming prepare() needs to translate the input SQL from your "standard" syntax into the DBMS-specific syntax, you just apply the transform in your subclass's prepare(), then pass the transformed SQL off to DBI via SUPER::prepare(). The plumbing is pretty simple.
I do something similar to what you describe in DBIx::Chart & DBD::Chart:
when a query includes chart rendering syntax, DBIx::Chart hands the
relevant SQL bits off to the source DBD drivers via the DBI base class
methods, collects the stmt handles, and passes them into DBD::Chart, which fetches the data from the stmt handles for rendering. Note that
DBIx::Chart subclasses DBI, and doesn't add any methods, just SQL syntax
extensions. In fact, if DBI had been subclassable when I first hacked
DBD::Chart together, I would likely have just embedded its logic in
DBIx::Chart.
Good luck, Dean Arnold Presicient Corp.
