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".
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". Tim. 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
