FAQ
A discussion started on dbi-users which I thought seemed more appropriate to
continue on dbi-dev assuming it caries on in the direction of a design
discussion. I have quoted the important parts of each original message below,
to get it started. -- Darren Duncan


-------- Forwarded Message --------
Subject: Perl 6 and DBI
Date: Thu, 5 Feb 2015 00:23:40 -0000
From: Greg Sabino Mullane <greg@turnstep.com>
To: dbi-users@perl.org

As you may have heard, Larry Wall gave a speech recently declaring
the goal of releasing Perl 6 this year, 2015. Honestly, there
is little chance of me using Perl 6 until it has a good, working
DBI. Anyone know the state of things with DBI and Perl6? Is the
goal still to implement what is basically DBI v2, or perhaps
someone is working on a simple port of the existing DBI? Is
a working DBI even on their list of blocker features for a release?


-------- Forwarded Message --------
Subject: Re: Perl 6 and DBI
Date: Wed, 4 Feb 2015 16:28:15 -0800
From: David E. Wheeler <david@justatheory.com>
To: Greg Sabino Mullane <greg@turnstep.com>
CC: dbi-users@perl.org

This goes for me, too, and many, many other people too, I’ve little doubt.


-------- Forwarded Message --------
Subject: Re: Perl 6 and DBI
Date: Wed, 04 Feb 2015 17:19:54 -0800
From: Darren Duncan <darren@darrenduncan.net>
To: David E. Wheeler <david@justatheory.com>, Greg Sabino Mullane
<greg@turnstep.com>
CC: dbi-users@perl.org

And in that case, there would/should be a discussion about what form this DBI
for Perl 6 should take.

Personally I think one of the most important design changes DBI should make is
that DBI becomes an API spec that drivers/engines must conform to in order to be
certifiably compatible. Part of the API is that user code can query the
driver/engine to ask, "do you implement DBI" or "do you implement this version
of the DBI API" etc.

DBI should not be an actual code layer that applications have to go through in
order to talk with the driver/engine, as it is now.

However, there can exist Perl 6 roles or other shared libraries that a
driver/engine may optionally use to help it implement the API rather than
rolling its own.

Think of the kind of revolution that PSGI brought by working this way, just
defining an API or protocol to conform to, rather than "being" a module that
everything had to use. DBI should do the same thing.

The actual details of the API / common interface are an orthogonal matter. The
key thing I'm looking for is no mandatory shared code between engines/drivers.

I also believe that what I said, the no mandatory shared code, would also work
just as well in any language, including a major new Perl 5 version.


-------- Forwarded Message --------
Subject: Re: Perl 6 and DBI
Date: Wed, 4 Feb 2015 21:52:39 -0600
From: David Nicol <davidnicol@gmail.com>
To: Darren Duncan <darren@darrenduncan.net>
CC: David E. Wheeler <david@justatheory.com>, Greg Sabino Mullane
<greg@turnstep.com>, dbi-users@perl.org <dbi-users@perl.org>

Does this mean the floor is open for brainstorming? I'd like to see more
transparent integration, so p6+dbi would be like pl/sql or pro*C or whatever
that language Peoplesoft scripts used to be in that I was working with when I
wrote DBIx::bind_param_inline.

http://perlbuzz.com/2008/12/database-access-in-perl-6-is-coming-along-nicely.html

http://www.mail-archive.com/dbdi-dev@perl.org/maillist.html
doesn't have anything new since 2011.

Search Discussions

  • H.Merijn Brand at Feb 5, 2015 at 8:09 am

    On Wed, 04 Feb 2015 20:07:11 -0800, Darren Duncan wrote:

    A discussion started on dbi-users which I thought seemed more appropriate to
    continue on dbi-dev assuming it caries on in the direction of a design
    discussion. I have quoted the important parts of each original message below,
    to get it started. -- Darren Duncan
    FWIW I tested perl6 with Inline::Perl5 and perl5's DBI, and it works :)
    If not having DBI for perl6 is the *only* reason not to start with
    perl6, then start today!

    OTOH there are quite a lot of issues yet to be fixed. e.g. Inline::Perl5
    does not yet support streams and file handles amongst which are the
    invaluable scalar IO types. That is a known issue and work is in
    progress right now.

    $ cat dbi5.pl
    #!/pro/bin/perl

    use 5.20.0;
    use warnings;

    use DBI;

    my $dbh = DBI->connect ("dbi:Pg:");

    my $sth = $dbh->prepare ("select count (*) from url");
    $sth->execute;
    $sth->bind_columns (\my $count);
    $sth->fetch;
    say $count;
    $ perl dbi5.pl
    491826

    $ cat dbi6.pl
    #!perl6

    use v6;
    use Slang::Tuxic;
    use Inline::Perl5;

    my $p5 = Inline::Perl5.new;

    $p5.use ("DBI");

    my $dbh = $p5.invoke ("DBI", "connect", "dbi:Pg:");

    my $sth = $dbh.prepare ("select count (*) from url");
    $sth.execute;
    my @count = $sth.fetchrow_array;
    @count[0].say;
    $ perl6 dbi6.pl
    491826

    I didn't yet find the correct syntax for bind_columns in Inline::Perl5
    -------- Forwarded Message --------
    Subject: Perl 6 and DBI
    Date: Thu, 5 Feb 2015 00:23:40 -0000
    From: Greg Sabino Mullane <greg@turnstep.com>
    To: dbi-users@perl.org

    As you may have heard, Larry Wall gave a speech recently declaring
    the goal of releasing Perl 6 this year, 2015. Honestly, there
    is little chance of me using Perl 6 until it has a good, working
    DBI. Anyone know the state of things with DBI and Perl6? Is the
    goal still to implement what is basically DBI v2, or perhaps
    someone is working on a simple port of the existing DBI? Is
    a working DBI even on their list of blocker features for a release?


    -------- Forwarded Message --------
    Subject: Re: Perl 6 and DBI
    Date: Wed, 4 Feb 2015 16:28:15 -0800
    From: David E. Wheeler <david@justatheory.com>
    To: Greg Sabino Mullane <greg@turnstep.com>
    CC: dbi-users@perl.org

    This goes for me, too, and many, many other people too, I’ve little doubt.


    -------- Forwarded Message --------
    Subject: Re: Perl 6 and DBI
    Date: Wed, 04 Feb 2015 17:19:54 -0800
    From: Darren Duncan <darren@darrenduncan.net>
    To: David E. Wheeler <david@justatheory.com>, Greg Sabino Mullane
    <greg@turnstep.com>
    CC: dbi-users@perl.org

    And in that case, there would/should be a discussion about what form this DBI
    for Perl 6 should take.

    Personally I think one of the most important design changes DBI should make is
    that DBI becomes an API spec that drivers/engines must conform to in order to be
    certifiably compatible. Part of the API is that user code can query the
    driver/engine to ask, "do you implement DBI" or "do you implement this version
    of the DBI API" etc.

    DBI should not be an actual code layer that applications have to go through in
    order to talk with the driver/engine, as it is now.

    However, there can exist Perl 6 roles or other shared libraries that a
    driver/engine may optionally use to help it implement the API rather than
    rolling its own.

    Think of the kind of revolution that PSGI brought by working this way, just
    defining an API or protocol to conform to, rather than "being" a module that
    everything had to use. DBI should do the same thing.

    The actual details of the API / common interface are an orthogonal matter. The
    key thing I'm looking for is no mandatory shared code between engines/drivers.

    I also believe that what I said, the no mandatory shared code, would also work
    just as well in any language, including a major new Perl 5 version.


    -------- Forwarded Message --------
    Subject: Re: Perl 6 and DBI
    Date: Wed, 4 Feb 2015 21:52:39 -0600
    From: David Nicol <davidnicol@gmail.com>
    To: Darren Duncan <darren@darrenduncan.net>
    CC: David E. Wheeler <david@justatheory.com>, Greg Sabino Mullane
    <greg@turnstep.com>, dbi-users@perl.org <dbi-users@perl.org>

    Does this mean the floor is open for brainstorming? I'd like to see more
    transparent integration, so p6+dbi would be like pl/sql or pro*C or whatever
    that language Peoplesoft scripts used to be in that I was working with when I
    wrote DBIx::bind_param_inline.

    http://perlbuzz.com/2008/12/database-access-in-perl-6-is-coming-along-nicely.html

    http://www.mail-archive.com/dbdi-dev@perl.org/maillist.html
    doesn't have anything new since 2011.

    --
    H.Merijn Brand http://tux.nl Perl Monger http://amsterdam.pm.org/
    using perl5.00307 .. 5.21 porting perl5 on HP-UX, AIX, and openSUSE
    http://mirrors.develooper.com/hpux/ http://www.test-smoke.org/
    http://qa.perl.org http://www.goldmark.org/jeff/stupid-disclaimers/
  • Tim Bunce at Feb 6, 2015 at 6:54 pm

    On Thu, Feb 05, 2015 at 09:09:25AM +0100, H.Merijn Brand wrote:
    On Wed, 04 Feb 2015 20:07:11 -0800, Darren Duncan
    wrote:
    A discussion started on dbi-users which I thought seemed more appropriate to
    continue on dbi-dev assuming it caries on in the direction of a design
    discussion. I have quoted the important parts of each original message below,
    to get it started. -- Darren Duncan
    FWIW I tested perl6 with Inline::Perl5 and perl5's DBI, and it works :)
    If not having DBI for perl6 is the *only* reason not to start with
    perl6, then start today!
    use v6;
    use Slang::Tuxic;
    use Inline::Perl5;

    my $p5 = Inline::Perl5.new;
    $p5.use ("DBI");

    my $dbh = $p5.invoke ("DBI", "connect", "dbi:Pg:");
    my $sth = $dbh.prepare ("select count (*) from url");
    $sth.execute;
    my @count = $sth.fetchrow_array;
    @count[0].say;
    $ perl6 dbi6.pl
    491826

    I didn't yet find the correct syntax for bind_columns in Inline::Perl5
    That's relying on 'raw' Inline::Perl5 semantics. There's probably value
    in creating a module that uses Inline::Perl5 behind the scenes but
    presents a more friendly API, eg for bind_columns etc.

    Tim.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupdbi-dev @
categoriesperl
postedFeb 5, '15 at 4:07a
activeFeb 6, '15 at 6:54p
posts3
users3
websitedbi.perl.org

People

Translate

site design / logo © 2019 Grokbase