On Tue, Dec 6, 2011 at 5:54 AM, Jens Rehsack <rehs...@googlemail.com> wrote:
> 2011/12/2 Brendan Byrd <sineswi...@gmail.com>: > > > > 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. > I'm still not able to even install this via CPAN, and I'm fine with using S:S / D:D:SE. > > 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? > Who says S:S requires files? It has methods for pulling individual rows, seeking, inserting, etc. That could apply for anything. Sure, DBD::Google / Amazon are unmaintained, but it shows that S:S can go outside the bounds of a file. Why not take the additions you have for DBD::Sys and put them in S:S? It just seems to be a better home and a better name for code that parses the SQL and defines the data types. 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. > Yeah, though I'm still using it, for lack of a better "table importer". I just discovered that D:AD suffers from the same quoted tables problem. It doesn't know what to do with something like SELECT * FROM "types", despite having a table called types. I can patch it unless you have a better direction on what kind of module I should use to pass an ARRAY table. And if you're going to say DBD::Sys again, can you at least provide some sample code on how that would work? I'm still not understanding the concept, outside of it being an abstract /proc DBD. > > 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? > Like you said yourself: DBD::Sys --> DBI::DBD::SqlEngine --> DBI::SQL::Nano --> SQL::Statement Which are in three different CPAN packages. By "abstract DBD object", I mean the non-standard form of a database. Not Oracle, MS SQL, MySQL, but files, trees/objects, and other abstract forms of 2D/3D relational data. S:S makes that possible, but why is the code fragmented all over creation, overloading itself upon itself? How is somebody supposed to figure out how to create interfaces if there is no indication on if I should be following SQL::Statement::Embed, DBI::DBD, or some undocumented method on using DBD::Sys? > 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. > DBI - Yes, I do, if I need to use private variables DBIC - Yeah, I know that's another topic and probably another mailing list, but I am trying to use these for DBIC. S:D:R - Usually, yes. If I want to change the data types, I'll need to create a new Role. If I want to change the Reserved Words, I need to create a new Role. Same goes for removing any of the other sections. > > 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. > Then that's a bit too simple for my needs. If I'm querying a few tables from 300 hosts (which is not an uncommon request), I'd like to be able to get the data as fast as the hosts give it to me. S:S gives me that power. Hell, I've already tweaked Net::SNMP to run as fast as possible (with whatever load requirements are thrown at it), so I don't want that to be bottleneck'd by the DBD. > 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. > Well, I've written separate subs in the ::db namespace for each driver. I'll open to re-factoring some of that code into S:S and D:D:SE. > > 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. > I'm just talking about single row operations (ie: non-blocking mode), not multi-threaded applications. And man, after all the flack I get just mentioning common::sense, you actually bring up a Marc Lehmann module?? > > 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. > Probably, but I'm not exactly asking for multiple programmers to jump on my team, either. I just wanted a SNMP DBD that was fairly complete and worth using. Some of that requires some complexities, but at least S:S has what I need to solve those. And hell, even I have my limits on how far down the rabbit hole I go... Speaking of which, that S:S:Functions patch is ready to go under RT #72638. -- Brendan Byrd/SineSwiper <sineswi...@gmail.com>
