2011/11/30 Brendan Byrd <sineswi...@gmail.com>: Please don't leave ML out ;) Adding back again.
> On Wed, Nov 30, 2011 at 4:14 AM, Jens Rehsack <rehs...@googlemail.com> > wrote: >> >> The reason is quite simple. The "corrected" table name is not corrected >> from >> the point of view of the storage backend (in case of DBD::CSV the file >> names on disk), >> they are corrected from point of view of SQL standard and SQL indentifier >> attribute (lower case all, upper case all, leave them as they were). >> >> The storage backend might need to do it's own correction, as DBD::File >> does. > > That's fine. I just added this to open_table: > > # enforce proper capitalization (even though we probably don't need it) > $table = index($table, '"') == -1 ? lc $table : $table; > > Which was partly borrowed from S:S' original lowercasing routine. Might be > worthy of throwing this into the starter open_tables sub in S:S:Embed docs, > since other folks might want the SQL level table name. I think I shall go to move the content of S::S::Embed fully into DBI::DBD::SqlEngine and simply refer from S::S::E to DBI::DBD::SE. Don't cramp at S::S - DBI makes the rules! So DBI::DBD::SqlEngine and subsequent docs must be read. >> > If we correct it to enforce proper >> > ODBC case-sensitivity, that may suddenly break the DBD and users of >> > those >> > DBDs that are expecting to query a CSV DB via "SELECT * FROM >> > UPPERCASE_filename" and getting an error because it's now going to >> > convert >> > that to lowercase. If we don't correct it, there's the potential for >> > two >> > different cased files to have the same table key and screwing stuff up >> > with >> > JOIN. (Yeah, it's rare for somebody to actually be using both "FOOBAR" >> > and >> > "foobar" in the same query...) >> >> I hope this wouldn't happen, because SQL::Statement should detect (and >> internally >> correct /FOOBAR/ and /foobar/ into /foobar/, but in fact, I'm not sure. >> You might go ahead and add a test for this. > > Well, that's my point. If you have two tables FOOBAR and foobar in a JOIN, > technically, from SQL's POV, they are the same table, and S:S might balk at > a unsupported self-join. Though, the user actually wanted to hit two > different files. If the user wants that, he must quote the identifiers! > It's a (very) minor edge case, but I'll look at a test for that. The test case should prove correct behaviour of S::S - not obscure and wrong behaviour. >> > I guess this is delegating the enforcement of these standards to the >> > DBD, or >> > should it be higher up? >> >> This is handled by the base class of all SQL::Statement based DBD's, in >> DBI::DBD::SqlEngine. See sql_identifier_case and >> sql_quoted_identifier_case >> $dbh attribute description. >> DBD::File acts upon the values of those attributes, but other DBD's might >> implement other actions. > > Well, the separation of the SQL and storage layers makes sense. I guess > that's what you were driving at with your conversation on IRC: better > separation of proper layers. It just not simply a question of making sense, it's a critical to clarify responsibilities. S::S delegates responsibility for reading / persisting data to the table and the table instrumentation to a derived engine instance. >> I agree in fundamental issues in S::S and DBI::DBD interaction with >> standards. >> The reason to create DBI::DBD::SqlEngine was primarily to introduce an >> abstraction layer to hide SQL::Statement details and issues. From view of >> any DBD derived from DBI::DBD::SqlEngine, details should be hidden in >> SqlEngine. All changes we make must not affect this API for now. >> >> We all agree (all we talked 2 years ago named Merijn Brand, Martin Evans, >> Tim Bunce and myself), that we might need one big shot for a new >> DBI::DBD::SqlEngine API - but for stability reasons please no regular >> "improvements". I see how long it took for example for Steffen Winkler to >> improve his DBD::MO (or myself for DBD::AnyData) to the new >> Pure-Perl-DBD-API. > > I guess that's fine. I understand how there's potentially 50 different DBDs > out there that could have issues with backwards compatibility with S:S and > D:D:SE, though it has to get broken at some point. I see S:S (or the whole > SqlEngine suite) as something that can potentially be as powerful as a real > DB. Throw everything into DBIC with a Federated DB of all of your data, > relationalized to all the right points, and you end up with a single > interface for ALL data. (Sorry, that's another thread...) Well, not really. I pointed DBD::Sys to you yesterday. Keep in mind, you can extend it with plugins. Keep in mind, those plugins can do several things. One plugin could query SNMP sources, another plugin can query oracle db stats, etc. pp. > But, we still need an outlet to put these things in. I keep hearing about a > 2.0 version, and if it doesn't already, let's get the repository built. > Break all we want as this new version isn't exactly meant to be backwards > compatible (but still have the same goal in mind). 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. 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. >> Further, I've seen you got a lot of DBI/DBD related information yesterday >> (I was busy at $work and couldn't talk on IRC). What was still missing >> was enlightening you about DBI::DBD::SqlEngine and DBD::File/DBD::DBM >> internal details. Probably we find a day were we can talk, but for the >> moment the guys guided you yesterday can help you further patching >> your own repository checkouts and create tests for your patches and >> guide you how to test dependent modules. >> >> I'm the last one who will reject good patches with tests on SQL::Statement >> and approvals for DBI and tests on DBI, DBD::CSV and DBD::Sys >> running fine. > > Cool. I'll probably continue to hang out in IRC. Also, I've attached the > DBD modules zipped up. > > That patch should be read this week. Finished with the coding, but it > failed 50 tests (probably most of the new ones), so I'm working through > those. > >> >> There is a reason for the >> http://search.cpan.org/dist/Bundle-Test-SQL-Statement/ >> distribution - it's test coverage. Probably Tux as DBD::CSV maintainer can >> agree >> that issues between SQL::Statement changes and Pure-Perl-DBD's are >> getting rarer since these Tests exist. > > So, is that just the location of all of the S:S tests? No, it shares the tests with SQL::Statement, but it increases requqired modules for the tests to avoid otherwise introduced circular dependencies ;) /Jens > -- > Brendan Byrd/SineSwiper <sineswi...@gmail.com> > Computer tech, Perl wizard, and all-around Internet guru >
