2010/8/16 Tim Bunce <tim.bu...@pobox.com>: > Rather than a skeleton I think I'd prefer an actual useful simple driver > with an implementation that's kept clean and clear enough for use as a > base for cloning. I.e., a "reference implementation".
I think, DBD::DBM is a good and clear reference implementation for DBD::File based drivers while DBD::Sys is nice to be used as reference for DBI::DBD::SqlEngine based ones. DBD::AnyData and DBD::CSV have both to many "backward compatibility" stuff (good for users, bad for new learning developers). But it doesn't contain documentation as "here is implemented abc because of xyz ..." - what a skeleton driver could contain at the right places. > It would also be handy if the driver had a name that was easy/safe to do > a global replace on. Then we could provide a "clone the driver" script > that would copy the driver source tree, including tests, and change the > package names etc. Ideally the new driver tree, with the new name, > should "just work". Than I wouldn't fill to much of intelligence into the driver ... DBD::Sys cannot be cloned in a trivial way - DBD::DBM should work, DBD::AnyData should work, but both have a lot of logic in them, which might be irrelevant for the requestor. And I don't want to create two new stupid examples DBD's. Best regards, Jens > On Sun, Aug 08, 2010 at 05:44:38PM +0000, Jens Rehsack wrote: >> Hi, >> >> this morning the mail below arrives at my Inbox (in German). >> >> I tried to answer at my best, but it feels very difficult to me to >> explain some things clearer than I did in the documentation of >> DBI::DBD::SqlEngine, DBD::File and DBD::File::Developers. >> >> Than I've got an idea: the request for an example driver wasn't >> well asked - Steffen doesn't need an example (we have a lot and >> our documentation is good at all), Steffen needs a skeleton. >> >> Probably it's not that what "we" want - but I think it's a good >> feature request and it's reasonable for authors to ask for it. >> >> In addition to DBI::DBD::Metadata, can we provide skeleton drivers >> for: >> 1) DBD::File bases DBD's, >> 2) DBI::DBD::SqlEngine based DBD's, and/or >> 3) standalone DBD's (with or without XS)? >> >> Writing the first and seconds shouldn't be a problem for me, but >> I still have in mind what I first learned about writing a new DBD >> from DBI::DBD: "The first rule for creating a new database driver >> for the Perl DBI is very simple: DON'T!" >> >> With the above skeletons, we could open a door to more DBD's. >> I - speaking only for me - want that. >> >> What do the others want? >> >> Best regards, >> Jens >> >> -------- Original Message -------- >> Subject: here the english version >> Date: Sun, 08 Aug 2010 19:13:27 +0200 >> From: Steffen Winkler <steffen.wink...@gmx.net> >> To: Jens Rehsack <rehs...@googlemail.com> >> >> Hi Jens! >> >> Before I went to the YAPC I started to change my driver. And then I gave up. >> >> At the time I created DBD::PO I started with DBD::CSV, a running >> software. Than I changed a lot and at the end was it DBD::PO. But I >> do not know exactly what I does. Now I want do create my driver more >> professional. >> >> What I expect and where are the problems? >> >> The first thing quickly becomes clear which packages I need. >> >> Something is not always clear which global variables for which I >> must always provide. >> >> Rather it was unclear what methods should I implement in which >> package and how the parameters are and what they return. >> >> The documentation >> http://search.cpan.org/~timb/DBI-1.613_70/lib/DBD/File/Developers.pod >> describes a lot methods verbally only. But I can not really read >> what is mandantory and what is optional. The verbal description >> alone is only 50% useful. >> >> DBD::CSV or other special drivers are not really helpful as an >> example. An example needs more comments an expanations. >> >> As an example, I would imagine that the database table could look like this: >> key1 >> value1 >> key2 >> value2 >> The fields should be static: >> key >> value >> >> The DBD::CSV is complex. It is a mix between a driver and format >> specials. It also supports both DBI interfaces. This reduces the >> readibility too. >> >> An idea was to write such a minimal driver and place them at >> example/dbd_file/blabla.pm in the distribution. Than a writer of a >> new driver has a running example and can adapt this step by step. >> >> Please tell me your opinion. >> >> Greetings from Steffen. >> -- >> Neu: GMX De-Mail - Einfach wie E-Mail, sicher wie ein Brief! >> Jetzt De-Mail-Adresse reservieren: http://portal.gmx.net/de/go/demail >
