2011/12/2 Brendan Byrd <sineswi...@gmail.com>: > On Thu, Dec 1, 2011 at 1:27 AM, Jens Rehsack <rehs...@googlemail.com> wrote: >> >> > On Wed, Nov 30, 2011 at 4:14 AM, Jens Rehsack <rehs...@googlemail.com> >> > wrote: >> > But, we still need an outlet to put these things in. I keep hearing >> > about a >> I see no reason to do this _now_. Nothing you desire needs S::S changes, >> only the way you desire it. That's why I tried to lead you another way >> yesterday. > > Well, as long as it's reflected as a schema all throughout, that's fine. > However, I'm not convinced that it's not going to strip out the schema from > the SQL, unless DBD::Sys is overloading the affected subs.
It follows a completely different concept - it takes the things you want to prefix before identifier names in $dbh private attributes. Attribute names encode table name - see http://search.cpan.org/dist/DBD-Sys/lib/DBD/Sys.pm#Metadata for details. This name construction is not finalized, it could be extended if necessary. >> Remember the very first important thing you learned when you digged >> how to write a new DBD: "Don't do it!" It's still important to remember >> this. >> If it's not necessary, avoid it. > > > Okay, so why does mine need to go in the DBD::Sys::Plugin namespace, and > not: > > DBD::File > DBD::CSV > DBD::RAM > DBD::Chart > DBD::PO > DBD::Google > DBD::Amazon > DBD::Mock > DBD::Excel > DBD::DBM > etc., etc., etc. > > ? Well, you want to fetch values from an snmp daemon? So you're not going to read it from a file. Because of this, everything derived from DBD::File doesn't care. DBD::Google and DBD::Amazon are unmaintained, DBD:RAM is temporarily a wrapper around S::S temp tables and DBD::Mock - well, it's clear why it's something unwanted for your goal, isn't it? Remaining is now DBD::AnyData - but it's depreciated because of no time. It needs some separation between storage and coding layers and some more interfaces (eg. access structure). So it's not a good point to start, too. > Granted, I imagine some of that has to do with timeframes (since DBD::Sys > appears to be a newer platform), but there seems to a lack of uniformity > with it all. I'm not really blaming anybody for that, but it's just has > ended up that way. Four different subclasses overloads from three different > CPAN packages seem to link together the "abstract DBD object" code. Yet > there is no indication on which one to start. Four different subclasses? o.O >From three different CPAN packages? Abstract DBD object? Well, I don't see where you are. Start analyzing from http://search.cpan.org/dist/DBD-Sys/ by clicking on DBD::Sys - and from there follow the linked pages. If you have additional questions, please (as long as you don't ask to blame CPAN module structure and way of installation / package management) ask with some more details ;) > And all of this custom code per driver that lies OUTSIDE of the driver. DBI > needs a private variable extension. DBIx::...::Storage::DBI apparently > needs a module for each DBD. (Yet there isn't a generic one for D:D:SE or > S:S.) SQL::Dialects::Role needs its own module, but at least THAT is > extensible from within the DBD. You don't need that (SQL::Dialects::Role)! You might not understand this, but step back. And I can't help you with any kind of DBIx integration - and I wouldn't recommend to bundle DBD::* distributions with DBIx::*::Storage::* modules. > Heck, I'm not even against re-writing the SNMP module for DBD::Sys. > (Especially since I can't seem to get rid of this limit_dialect error, and > as soon as I correct some things to use D:D:SE, now IT is f'ing complaining > about the schema.table format.) It just seems like it would be an odd fit > in front of all of those other plugins that are clearly only related to > filesystems and OS stats. Well, other plugins are very welcome. But I've created some common examples only (remember: free time project - not got paid for it). > Plus, I'm still not getting where this is supposed to start. > DBD::Sys::Plugin's POD is barely a page, and most of the example plugins > almost look too simple. They are! There is no rocket science. > Just get_table_name, get_col_names, and > collect_data? You have to provide all data at once - see DBD::Sys::Plugin and DBD::Sys::CompositeTable for reasons. > What about fetch_row or foreign_key_info? fetch_row is not required - you can loop over the list of all rows you got. And foreign_key_info is a nice to have for SQL::Statement v2 and DBI::DBD::SqlEngine v2 (with data dictionary support). I would accept a patch for DBD::Sys what adds foreign key information like DBI::DBD::SqlEngine or DBD::File handles it (Merijn can probably say more about that, he introduced a PoC for this in DBD::CSV and it became generalized during DBD::File / DBI::DBD::SqlEngine refactoring. > What if I don't > want to collect all of the data at once? You probably want to have a look at Coro in that situations. > What if I want write support? I > just don't see how a complex module fits here, and nor do I see what > complexities it solves for me. You don't have a complex module. You made it complex, but it isn't. See > http://www.csd.uwo.ca/staff/magi/personal/humour/Computer_Audience/The%20Parable%20of%20the%20Two%20Programmers.html Looks to me you're much more an Alan than me (in my free time projects). Working in contracts, sometimes I morph into an Alan - but when I realize it, I try to morph back or leave the project. Cheers, Jens > -- > Brendan Byrd/SineSwiper <sineswi...@gmail.com>
