On 1/19/04 10:46 PM, Harry Jackson wrote:
> I am sorry if I am reading things incorrectly.
>
> Do you want the DBI to load default date handling facilities unless
> otherwise instructed ie.(load some other handlers).
No, it wouldn't load any handlers at all unless explicitly told to do so.
It's j
John Siracusa wrote:
"ENORMOUS" in terms of memory overhead? It depends on the context, I guess.
If you don't make something required, then no one can use the parse_*() and
format_*() functions in DBI unless they first explicitly register column
type handlers for each DBD. That's a pain. I'd rat
On 1/19/04 7:41 PM, Tim Bunce wrote:
> On Mon, Jan 19, 2004 at 07:19:05PM -0500, John Siracusa wrote:
>> What about the other direction, allowing arbitrary code
>> (\&my_deflate_thingie) to run during calls like:
>>
>> $sth->execute($val1, $val2, ...);
>
> I'm much less inclined to do that. S
On Mon, Jan 19, 2004 at 07:19:05PM -0500, John Siracusa wrote:
> On 1/19/04 7:13 PM, Tim Bunce wrote:
> > On Mon, Jan 19, 2004 at 11:19:04PM +, Tim Bunce wrote:
> >> When I said "But I do think a "column type system" is needed to
> >> provide the hooks that'll enable you to do what you want" I'
On 1/19/04 7:13 PM, Tim Bunce wrote:
> On Mon, Jan 19, 2004 at 11:19:04PM +, Tim Bunce wrote:
>> When I said "But I do think a "column type system" is needed to
>> provide the hooks that'll enable you to do what you want" I'm
>> thinking in terms of some way to say "use this code ref by default
On Mon, Jan 19, 2004 at 11:19:04PM +, Tim Bunce wrote:
> On Mon, Jan 19, 2004 at 02:32:17PM -0500, John Siracusa wrote:
> > On 1/19/04 2:22 PM, Tim Bunce wrote:
> > > Short answer: no.
> >
> > Can I please have the long answer? :)
>
> I have no time, I've a plane to catch. Perhaps others can
On Mon, Jan 19, 2004 at 02:32:17PM -0500, John Siracusa wrote:
> On 1/19/04 2:22 PM, Tim Bunce wrote:
> > Short answer: no.
>
> Can I please have the long answer? :)
I have no time, I've a plane to catch. Perhaps others can share
there views and examples.
> Passing code
> refs to bind_columns()
On 1/19/04 2:22 PM, Tim Bunce wrote:
> Short answer: no.
Can I please have the long answer? :) I really think this type of thing is
common enough that, at the very least, there should be convenient hooks for
parsing and formatting dates (or possibly any column types). Passing code
refs to bind_c
Short answer: no. If you want to use DateTime then I'd recommend
the DateTime::Format::DBI module or something like it:
http://search.cpan.org/~cfaerber/DateTime-Format-DBI-0.031/lib/DateTime/Format/DBI.pm
Tim.
On Mon, Jan 19, 2004 at 10:15:05AM -0500, John Siracusa wrote:
> On 1/18/04 6:33 PM,
On 1/19/04 4:28 AM, Matt Sergeant wrote:
> On 18 Jan 2004, at 17:14, John Siracusa wrote:
>> This topic came up before, when DateTime was just getting off the ground.
>> DateTime is a lot more mature now, and I still think it's a good idea :)
>>
>> Along those lines, all of my DBI wrappers have al
On 1/18/04 6:33 PM, Tim Bunce wrote:
> My preference is that after doing:
>
> $sth->bind_column(1, undef, SQL_DATE);
> $sth->bind_column(2, undef, SQL_DATETIME);
> $sth->bind_column(3, undef, SQL_TIMESTAMP);
>
> the driver should ensure that it returns values for those three column in the
> corre
On 18 Jan 2004, at 17:14, John Siracusa wrote:
This topic came up before, when DateTime was just getting off the
ground.
DateTime is a lot more mature now, and I still think it's a good idea
:)
Along those lines, all of my DBI wrappers have also had a uniform API
for
DB-specific date parsing a
On Sun, Jan 18, 2004 at 12:14:22PM -0500, John Siracusa wrote:
> On 1/12/04 10:47 AM, Tim Bunce wrote:
> > And this is what I'd like you to be thinking about
> > (mostly directed at driver authors):
> >
> > A. What changes you'd like to see in the DBI API.
>
> This topic came up before, when Date
On 1/12/04 10:47 AM, Tim Bunce wrote:
> And this is what I'd like you to be thinking about
> (mostly directed at driver authors):
>
> A. What changes you'd like to see in the DBI API.
This topic came up before, when DateTime was just getting off the ground.
DateTime is a lot more mature now, and
On Mon, Jan 12, 2004 at 03:47:56PM +, Tim Bunce wrote:
> Plans:
>
> 1. Move DBI source code to http://sourceforge.net/projects/dbi/
Actually it'll be http://svn.perl.org/modules/dbi/ as I've decided
to use Subversion (http://subversion.tigris.org/) hosted by perl.org
> 2. Add a few dbi-dev
Henrik Tougaard wrote:
> Better support for transactions. At some point
> I predict that the RDBMS vendors will come up
> with transaction handles, and we need somewhere
> to hold them - I foresee several concurrent
> transactions on the same database handle.
Not to mention nested transactions (
On Wed, Jan 14, 2004 at 08:30:50AM +0100, Henrik Tougaard wrote:
> Jonathan Leffler skrev:
>
> > H.Merijn Brand wrote:
> >> Tim Bunce wrote:
> A. What changes you'd like to see in the DBI API.
> >> How about a new attribute: AutoTruncate
> >>
> >> so I can just put "grkaerhgkjehrgkaerhg" in
On Wed 14 Jan 2004 04:03, Jonathan Leffler <[EMAIL PROTECTED]> wrote:
> H.Merijn Brand wrote:
> > Tim Bunce wrote:
> >>>A. What changes you'd like to see in the DBI API.
> > How about a new attribute: AutoTruncate
> >
> > so I can just put "grkaerhgkjehrgkaerhg" in a varcar/char (3) and it will
>
Jonathan Leffler skrev:
> H.Merijn Brand wrote:
>> Tim Bunce wrote:
A. What changes you'd like to see in the DBI API.
>> How about a new attribute: AutoTruncate
>>
>> so I can just put "grkaerhgkjehrgkaerhg" in a varcar/char (3) and it
>> will store "grk"
>
> That happens anyway in DBD::Inf
H.Merijn Brand wrote:
Tim Bunce wrote:
A. What changes you'd like to see in the DBI API.
How about a new attribute: AutoTruncate
so I can just put "grkaerhgkjehrgkaerhg" in a varcar/char (3) and it will
store "grk"
That happens anyway in DBD::Informix - the DBMS does it. There is a
warning raise
> From: Henrik Tougaard <[EMAIL PROTECTED]>
> To: 'Tim Bunce' <[EMAIL PROTECTED]>, [EMAIL PROTECTED]
> Subject: RE: DBI version 2 - 3 API change suggestions
>
> 1)
> The Ingres Open/API has the possibility of doing
> async db-access, ie starting a data
>
> On Mon, Jan 12, 2004 at 05:53:00PM -0500, Jeff Urlwin wrote:
> > > Plans:
> > >
> > > 1. Move DBI source code to http://sourceforge.net/projects/dbi/
> >
> > Tim,
> >
> > On and Off I've thought about moving DBD::ODBC to a CVS
> repository and
> > searched for a tool that would take old
On Tue 13 Jan 2004 15:42, Tim Bunce <[EMAIL PROTECTED]> wrote:
> On Mon, Jan 12, 2004 at 04:59:38PM +0100, H.Merijn Brand wrote:
> >
> > > B. What changes you'd like to see in the DBD API
> > > (that's the DBI<->DBD interface).
> >
> > · All dbh handel offspring (statement handles and such)
> >
On Mon, Jan 12, 2004 at 04:59:38PM +0100, H.Merijn Brand wrote:
>
> > B. What changes you'd like to see in the DBD API
> > (that's the DBI<->DBD interface).
>
> · All dbh handel offspring (statement handles and such)
> available from the top level handle, for both status
> and cleanup pur
On Mon, Jan 12, 2004 at 05:53:00PM -0500, Jeff Urlwin wrote:
> > Plans:
> >
> > 1. Move DBI source code to http://sourceforge.net/projects/dbi/
>
> Tim,
>
> On and Off I've thought about moving DBD::ODBC to a CVS repository and
> searched for a tool that would take old tarballs of prior release
Tim Bunce skrev:
> A. What changes you'd like to see in the DBI API.
>
> B. What changes you'd like to see in the DBD API
> (that's the DBI<->DBD interface).
>
1)
The Ingres Open/API has the possibility of doing
async db-access, ie starting a database request
and then at a later point in
On Mon 12 Jan 2004 16:59, "H.Merijn Brand" <[EMAIL PROTECTED]> wrote:
> > A. What changes you'd like to see in the DBI API.
>
> Me and my colleages seem very satisfied :)
How about a new attribute: AutoTruncate
so I can just put "grkaerhgkjehrgkaerhg" in a varcar/char (3) and it will
store "grk"
> Plans:
>
> 1. Move DBI source code to http://sourceforge.net/projects/dbi/
>
Tim,
On and Off I've thought about moving DBD::ODBC to a CVS repository and
searched for a tool that would take old tarballs of prior releases and build
the CVS repository from the tarballs. Maybe I don't need to,
Maybe a conformance test script for driver writers ?
(or at least a template version...)
Dean Arnold
Presicient Corp.
www.presicient.com
On Mon 12 Jan 2004 16:47, Tim Bunce <[EMAIL PROTECTED]> wrote:
> Plans:
>
> 1. Move DBI source code to http://sourceforge.net/projects/dbi/
>
> 2. Add a few dbi-dev people as developers who can modify the source.
>
> 3. Fork off DBI v1 for maintenance and start work on DBI v2.
>
> The change
On Mon, 12 Jan 2004, Tim Bunce wrote:
> Plans:
>
> 1. Move DBI source code to http://sourceforge.net/projects/dbi/
>
> 2. Add a few dbi-dev people as developers who can modify the source.
Tim,
Pending permission from my employer, I'd like to volunteer as
maintainer for the DBI::Proxy.
Let
Plans:
1. Move DBI source code to http://sourceforge.net/projects/dbi/
2. Add a few dbi-dev people as developers who can modify the source.
3. Fork off DBI v1 for maintenance and start work on DBI v2.
The changes I'm considering for DBI v2 are minor for the DBI API
and only slightly more sig
32 matches
Mail list logo
