I have an additional reply to the following ...
At 10:25 PM +1000 7/9/05, Adam Kennedy wrote:
In any case, I still propose that DBI2 split the driver interface
into Roles. The main "DBI2::Role::Transport" role does ONLY what DBI
does best now. That is, connecting to the database, preparing and
At 9:27 PM -0700 7/10/05, Jonathan Leffler wrote:
This is not what DBI deals with - it deals more nearly with the CLI
syntax, where that is not, as far as I know, permitted.
My impression of DBI is that it is a stand-in of sorts for a SQL CLI,
and does or should do all of the same sorts of thi
At 10:25 PM +1000 7/9/05, Adam Kennedy wrote:
In any case, I still propose that DBI2 split the driver interface
into Roles. The main "DBI2::Role::Transport" role does ONLY what DBI
does best now. That is, connecting to the database, preparing and
sending queries, and fetching the results.
For
On 7/9/05, Robin Redeker <[EMAIL PROTECTED]> wrote:
> On Sat, Jul 09, 2005 at 07:36:10AM -0700, Larry Wall wrote:
> > : > Why does it have to be some sugared syntax when you can just simple
> > : > name it in the parameter list?
> > :
> > : Yes, but there seem to be quite some people who want
> > :
Jeffrey W. Baker skribis 2005-07-09 11:27 (-0700):
> > Oh drat - not the DBI connection string discussion again!
> There are certainly database-specific things to be worked around. An
> improvement to the current DSN scheme would be a URI, as discussed in
> the past. The leading dbi: on every DSN
Jonathan Leffler wrote:
I dunno which DBMS support prepare without a database connection, but I
would expect all the mainstream databases to require a database connection.
+1
I'm also far from convinced that there's any significant benefit in
separating the 'create a database handle' from t
On Sat, Jul 09, 2005 at 07:36:10AM -0700, Larry Wall wrote:
> : > Why does it have to be some sugared syntax when you can just simple
> : > name it in the parameter list?
> :
> : Yes, but there seem to be quite some people who want
> : a 'cool' syntax for it. (ie. ./method ()).
>
> I wasn't thi
On 7/9/05, Darren Duncan <[EMAIL PROTECTED]> wrote:
>
> At 1:22 AM -0700 7/9/05, Jonathan Leffler wrote:
> >On 7/4/05, Darren Duncan <[EMAIL PROTECTED] > wrote:
> >5. All details used to construct a connection handle should be
> >completely decomposed rather than shoved into an ungainly "data
> >s
On Sat, 2005-07-09 at 01:22 -0700, Jonathan Leffler wrote:
> Oh drat - not the DBI connection string discussion again!
>
> On 7/4/05, Darren Duncan <[EMAIL PROTECTED]> wrote:
>
> > 5. All details used to construct a connection handle should be
> > completely decomposed rather than shoved into an
Michael Hendricks wrote:
In other words, Huffman coding works and Perl6 hackers had better start
watching their waistlines. Or maybe we should spin it that Perl6 helps
reduce global warming ;)
Anyway, I collected a small sample (~300 lines each) of Perl5 code along
with "equivalent" Perl6 code.
In particular, the DBI must not mandate impossible levels of support from
the drivers. It will benefit you nothing if the DBI is immaculate and
wonderful and incredibly all-singing and all-dancing, but no-one can write a
driver for it because the requirements cannot be met by the actual DBMS tha
Oh drat - not the DBI connection string discussion again!
On 7/4/05, Darren Duncan <[EMAIL PROTECTED]> wrote:
> 5. All details used to construct a connection handle should be
> completely decomposed rather than shoved into an ungainly "data
> source". Examples of what should be distinct (not all
12 matches
Mail list logo
