On Sat, Sep 24, 2011 at 12:30 AM, Darren Duncan <dar...@darrenduncan.net>wrote:
> Brendan Byrd wrote: > >> Yeah, that sounds right. So would this eventually become its own DBD >> module? >> > > Yes and no. It would not natively be a DBD module, but a separate module > can exist that is a DBD module which wraps it. Kind of like how you have > both SQLite and DBD::SQLite, say. So, it's more or less its own "meta-database" that talks to other database systems. Wouldn't this (or at least parts of it) essentially be a next-generation SQL::Statement engine? After all, they have a pretty good framework, but it doesn't support everything. Modules like DBD::CSV or DBD::File would benefit from having a fully 2003 compatible SQL. I'm still having trouble understanding the process, though. I mean, I looked through the three module categories. There actually isn't much code there. But, you have a* **LOT* of documentation. I mean, you have two separate module sections just for documentation, totaling 32,876 words! The Muldis::D::Basics POD is 3,742 words alone. Hell, *Old Man and the Sea* is 26,560 words. You've literally already written a book of documentation. I dare say that if you spend that time on the actual code, it would be done by now. How would this work? Let's say I have the two databases in the primary email I sent. How would that work in Perl? Do I set up Muldis first with the two databases, and then log in via DBI to the DBD, which DBIC would interface against? Does the DBD basically talk to Muldis to do the dirty work, or is there some work that the DBD would need to take care of (like actually talking to the databases)? > Does it use DBI methods to figure out the specs of the system? > >> For example, you were saying "less capable things like DBD::CSV". Is that >> determined by querying get_info for the ODBC/ANSI capability data? >> > > It would use whatever means make sense, which might be starting with the > DBI methods for some basic functionality and then doing SELECT from the > INFORMATION_SCHEMA to provide enhanced functionality. > Yeah, I guess DBI doesn't have the entire schema in its methods, but neither do a lot of DBMS. -- Brendan Byrd/SineSwiper <sineswi...@gmail.com> Computer tech, PERL wizard, and all-around Internet guru
