Re: Table case sensitivity with SQL::Statement

2011/12/2 Brendan Byrd <[email protected]>:
> On Thu, Dec 1, 2011 at 1:27 AM, Jens Rehsack <[email protected]> wrote:
>>
>> > On Wed, Nov 30, 2011 at 4:14 AM, Jens Rehsack <[email protected]>
>> > 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 <[email protected]>