In order to help making the adoption of my module/framework easier, I am planning to make a front end for it that parses SQL strings for particular databases and turns them into SQL-representing objects. Such a wrapper is meant to be a drop-in replacement for DBI so that people simply get increased portability without changing any code, except for perhaps a few lines like the 'connect' invocations.
In order to get the best possible drop-in compatability, I could very reasonably not emulate DBI itself, but write a DBD module that sits behind the real DBI, which people then use as normal.
For context, assume that my code always invokes DBI using its object-oriented interface (if there is even a choice). Also for context, assume that all of my own code is pure-Perl (that may change later, but in the near term it won't).
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
