Re: DBI drivers by duck-typing

2011-09-21 Thread David Nicol
On Wed, Sep 21, 2011 at 7:27 PM, Darren Duncan > As for DBMS-specific hacks Another possible approach would be a strict interface that only allows some kind of "DBI creole" -- well, I suppose a lot of other persistence frameworks are that, pretty much.

Re: DBI drivers by duck-typing

2011-09-21 Thread Darren Duncan
Greg Sabino Mullane wrote: I believe that DBI should go away as an actual piece of code and instead be replaced by an API specification document, taking PSGI as inspiration. I'm having a hard time envisioning how this would work in practice. What I see is lots of duplicated code across the DBD

Re: DBI drivers by duck-typing

2011-09-21 Thread Greg Sabino Mullane
-BEGIN PGP SIGNED MESSAGE- Hash: RIPEMD160 > I believe that DBI should go away as an actual piece of code and instead be > replaced by an API specification document, taking PSGI as inspiration. I'm having a hard time envisioning how this would work in practice. What I see is lots of d

Re: DBI drivers by duck-typing

2011-09-13 Thread Darren Duncan
Tim Bunce wrote: On Mon, Sep 12, 2011 at 01:13:58PM -0700, Darren Duncan wrote: To be brief, ... Darren, if you want to do something really directly useful for the DBI ecosystem I would encorage you (or anyone else) to work on creating a DBI test suite that's independent of the DBI distributio

Re: DBI drivers by duck-typing

2011-09-13 Thread Tim Bunce
On Mon, Sep 12, 2011 at 01:13:58PM -0700, Darren Duncan wrote: > To be brief, ... Darren, if you want to do something really directly useful for the DBI ecosystem I would encorage you (or anyone else) to work on creating a DBI test suite that's independent of the DBI distribution. Tim. p.s. I'm

Re: DBI drivers by duck-typing

2011-09-13 Thread David Nicol
On Tue, Sep 13, 2011 at 2:07 AM, H.Merijn Brand wrote: > The fact that the DBI is restrictive (or restricted) is a good thing. > First of all most of the restrictions are based on well thoughtthrough > decisions based on speed and use of resources. I do not have to take > those decisions again whe

Re: DBI drivers by duck-typing

2011-09-13 Thread H.Merijn Brand
On Mon, 12 Sep 2011 19:23:02 -0700, Darren Duncan wrote: > Fundamentally I propose an inversion of control, where users invoke DBD > modules > directly that optionally invoke or compose DBI to help them, rather than > users > invoking DBI that uses DBD modules to help it. The other stuff flo

Re: DBI drivers by duck-typing

2011-09-12 Thread Darren Duncan
David Nicol wrote: Are you asking for something beyond documenting the DBI/DBD interface to the point where a DBD can be used more directly than through the DBI? Aside from requesting that everyone abandon the framework mentality? Are you asking for a stronger set of conventions in DBDs that wil

Re: DBI drivers by duck-typing

2011-09-12 Thread Darren Duncan
David Nicol wrote: On Mon, Sep 12, 2011 at 5:20 PM, Darren Duncan wrote: How mandatory, currently, is the "mandatory shared codebase?" Are there really traps and snares preventing a different framework from using DBD modules? I'm presuming that there aren't; ICBW. So getting away from the "f

Re: DBI drivers by duck-typing

2011-09-12 Thread David Nicol
On Mon, Sep 12, 2011 at 5:20 PM, Darren Duncan wrote: >> How mandatory, currently, is the "mandatory shared codebase?" Are >> there really traps and snares preventing >> a different framework from using DBD modules? I'm presuming that there >> aren't; ICBW. > So getting away from the "framework"

Re: DBI drivers by duck-typing

2011-09-12 Thread Darren Duncan
David Nicol wrote: On Mon, Sep 12, 2011 at 3:13 PM, Darren Duncan wrote: So what say you? I think you can do this without any change to DBI. You have your own DBI-like framework; you could declare that anything that passes your conformance suite is compliant, and offer low-impact patches to

Re: DBI drivers by duck-typing

2011-09-12 Thread David Nicol
On Mon, Sep 12, 2011 at 3:13 PM, Darren Duncan wrote: > > So what say you? > > -- Darren Duncan I think you can do this without any change to DBI. You have your own DBI-like framework; you could declare that anything that passes your conformance suite is compliant, and offer low-impact patches

Re: DBI drivers by duck-typing

2011-09-12 Thread Darren Duncan
I was sent a response to this off-list, part of which I'll reply to on-list. The response bit was: "What happens to the 'which drivers are available' part of the DBI interface?" To this I say: The API definition would say that each DBD has something which can be easily scanned for, and so an

Re: DBI drivers by duck-typing

2011-09-12 Thread Darren Duncan
Replying to myself, ... I believe that this fundamental design change can be accomplished with almost full or entirely backwards-compatibility to existing DBI-using codebases. This partly by a "DBI" package still being available which essentially provides shims for people saying "DBI->connect