On Monday 22 October 2001 05:50 am, Tim Bunce wrote:
> On Sun, Oct 21, 2001 at 03:12:01PM -0700, Jason W May wrote:
> >...
> > my $thingy = new Thingy;
> > my $data = { id => 473 };
> > $thingy->execute("lookup_employee", $data);
> > print "Employee $data->{id} is $data->{name} with salary
DBIx:: is appropriate. DBI:: is not. It seems like you should use SQL::
if you just work with abstract SQL statements (which the user then passes
to their database or uses in some other way), and DBIx:: if you'll
actually be talking to DBI/DBD underneath for the user.
You may want to join the p
$ grep -l fetchrow_hashref *
Changes
DBI.pm
DBI.xs <==
DBIXS.h
test.pl
Tim.
On Mon, Oct 22, 2001 at 04:52:35PM -0700, Terrence Brannon wrote:
>
> On Monday, October 22, 2001, at 01:32 PM, Wiedmann, Jochen wrote:
>
> >
> >> no, what I am saying is that I could not look at the DBI.pm
>
On Mon, Oct 22, 2001 at 04:42:18PM -0500, Michael A Chase wrote:
> DBI is open source. That includes the C source code. Look in the files
> with .xs and .c extensions.
And .xst - Driver.xst is going to be growing in importance soon.
I expect it to be the home of a new version of fetchall_array
On Monday, October 22, 2001, at 01:32 PM, Wiedmann, Jochen wrote:
>
>> no, what I am saying is that I could not look at the DBI.pm
>> source code
>> and find a fetchrow_hashref anywhere, although I wanted to
>> look at such
>> a function so that I could answer this question myself.
>
> Most of D
DBI is open source. That includes the C source code. Look in the files
with .xs and .c extensions.
--
Mac :})
** I normally forward private questions to the appropriate mail list. **
Give a hobbit a fish and he eats fish for a day.
Give a hobbit a ring and he eats fish for an age.
- Original
> no, what I am saying is that I could not look at the DBI.pm
> source code
> and find a fetchrow_hashref anywhere, although I wanted to
> look at such
> a function so that I could answer this question myself.
Most of DBI is written in C. However, fetchrow_hashref is
one of the exceptions, s
On Monday, October 22, 2001, at 12:01 AM, Wiedmann, Jochen wrote:
>
>> I could not figure this out because fetchrow_hashref must be
>> written in
>> C and not Perl
>
> There is no reason for writing fetchrow_hashref in C. Just try.
no, what I am saying is that I could not look at the DBI.pm sou
You might want to look into DBIx::AnyDBD too. It allows you to write a
database indendent module that can be subclassed for different DBD's.
You write generic top-level methods for your module and allow these to
be overridden by your DBD specific subclasses - nice. Your base class
would probabl
On Sun, Oct 21, 2001 at 03:12:01PM -0700, Jason W May wrote:
> I'm working on a module that I hope will provide a similar function for SQL
> code that the various templating modules provide for HTML generation.
>
> The goal is to move SQL code entirely out of the Perl, and to provide a very
> s
On Mon, Oct 22, 2001 at 09:01:30AM +0200, Wiedmann, Jochen wrote:
>
> > I could not figure this out because fetchrow_hashref must be
> > written in
> > C and not Perl
>
> There is no reason for writing fetchrow_hashref in C. Just try.
>
> > I want to know if
> > fetchrow_hashref calls fetchr
On Sun, Oct 21, 2001 at 12:55:31PM -0700, Terrence Brannon wrote:
>
> On Wednesday, October 17, 2001, at 02:48 AM, Tim Bunce wrote:
>
> >> The module I propose to develop (the second RFC of this email), makes
> >> it
> >> clear why this would be useful.
> >
> > Er, actually it's not very clear
Attached is a patch for DBI which defines the column_info
interface.
Steffen
*** DBI-1.20/DBI.pm Sat Aug 25 01:33:52 2001
--- DBI.pm Sat Oct 20 19:19:07 2001
***
*** 296,301
--- 296,302
tables => { U =>[1,6,'$catalog, $schema, $table, $type [,
13 matches
Mail list logo
