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. > 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. ? 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. 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. 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. 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. Just get_table_name, get_col_names, and collect_data? What about fetch_row or foreign_key_info? What if I don't want to collect all of the data at once? 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. -- Brendan Byrd/SineSwiper <sineswi...@gmail.com>
