Database access in Perl 6 is coming along nicely

| 21 Comments

Simon Cozens just posted to the Perl 6 internals list:

I just ran this code, which worked with the expected results:

use DBDI;
my $conn = DBDI::DriverManager.getConnection(
    "dbdi:SQLite3:test.db", "", "");
my $stm = $conn.createStatement();
my $rs = $stm.executeUpdate("CREATE TABLE foo (bar, baz)");
my $stm = $conn.prepareStatement(
   "INSERT INTO foo (bar, baz) VALUES (?, ?)");
$stm.setColumn(1, 123);
$stm.setColumn(2, "Thingy");
$stm.executeUpdate();

Merry Christmas, Simon

I love the smell of progress in the morning.

21 Comments

Oh, that's old news - four or five hours ago. I've got select() working as well since then...

I think underscore function naming looks better than camelcase and actually more perlish.

Ug, seconded, 32nd: please, no javaStyle methodNamingConventions.

Hhm, I have to say I'm a bit disappointed. That looks like Java.
I think I *could* live with CamelCase but why not just "prepare" instead of "prepareStement" and "execute" instead of "executeUpdate"? If you see $conn->prepare or $stmt->execute it should be pretty clear what's going on, right? What else could you prepare on a $conn or what else could you execute with a $stmt?
I would greatly appreciate if there still was a method named "execute". So that I'm not forced to write line noise if it's clear what the code is doing...

SQR has this way of embedding variables in the text of SQL that perl could emulate with a new kind of quoting. The example could look like


my($bar, $baz);
my $stm = $connh.prepare(<<sq<ESQL>);
INSERT INTO foo (bar, baz) VALUES ($bar, $baz)
ESQL
$bar = 123;
$baz = "Thingy";
$stm.execute();

presuming that sq< is the new deferred-resolution qq.

By the way, what wiki markup set does this system (perlbuzz) support?

@32nd & @siracusa - I think thats because DBI 2.0 uses JDBC as its API.

In itself I think this is a good thing and so could also live with CamelCase. Anyway we could easily add more perlish methods around it!

/I3az/

Re "I think thats because DBI 2.0 uses JDBC as its API" - that's not quite right in two ways.

"DBI 2.0" doesn't exist anywhere other than in my head and, so far, I've been unsuccessful in making time to actually work on it.

"JDBC as its API" is a little misleading - DBI 2.0 uses JDBC as the *driver* API, i.e., the interface between the DBI and the underlying driver (DBD), not the interface between applications and the DBI.

That's why Simon's example looks like Java JDBC, and that's a very good thing. It means that he doesn't need me, or anyone else, to agree on the API or semantics. They're all specified in great detail in the JDBC docs and the JDBC test suite.

Anyone wanting to follow Simon's example can work to the same well defined standard API.

There are two main areas of concern though:

1. There may be subtle issues in how data types and calling conventions translate between Java and Parrot/Perl6.
2. JDBC is a big API, effort should be factor out as much code as possible into modules that can be shared between drivers.

The dbdi-dev@perl.org (note the 'i' in dbdi) mailing list is a good place to discuss these and related issues. Email dbdi-dev-subscribe@perl.org to subscribe.

"Hey, someone made us a new bikeshed!"


"Still the wrong colour though!"

Cool news! I think we can use that in November wiki. Thank you!

Looks interesting. Congratulations Simon.

To the complainers: you earn the right to complain by doing work. If you don't like this interface, design a better one yourself in stead of whining...

> To the complainers: you earn the right to complain by doing work. If you don't like this interface, design a better one yourself in stead of whining...

Oh my, how we grow tired of these pointless arguments: There is a perfectly *working* interface in existance already, which is called DBI, there is no need for perl6 to design a completely new API, which is needlessly incompatible to perl5.

Why perl6 wants to turn everything into java and forces new and incomaptible apis into the perl language esacpes me. What's wrong with DBI that it needs an incompatible redesign?

I have to agree with Beef. Why switch to the most complicated Database API in existence. The DBI was beautiful because it was simple. It also made a nice underlying system on which you could build things like SQL::Abstract and DBIx::Class. The whole idea is that programmers shouldnt even be thinking about SQL unless it is absolutely necessary (usually, my DBA does all the thinking about SQL that is necessary, I just have to find a way to encode what he comes up with into SQL::Abstract'ese).

@Tim - Thanks for the clarification. It was a while back when I first heard u mention about DBI 2.0 plans for using JDBC as the driver API (was it on a Perlcast?).

@Simon - I like the colour on this bikeshed! Keep up the good work.

/I3az/

> To the complainers: you earn the right to complain by doing work.

Oh. I'm sorry that I made a comment. Didn't know that I don't have the right to.

> Oh. I'm sorry that I made a comment. Didn't know that I don't have the right to.

+1

Simon made a great job but Perl6 really needs perlstyle(1) kinda guide to follow.

Just out of interest, how many of you guys complaining actually use Perl 6? If it's zero, I'll carry on doing what I'm doing. If it's more than zero, please send a patch. Thanks.

Looks like this will be the first fork we will have for perl6. I'm not doing anything to help. Shame on me! But I think that maybe the module called DBI 2.0 could be called JDBC. And the equivalent to DBI should be called DBI 2.0.

BUZZ!!

I wonder how many people complaining here know that the Tim Bunce who created and maintains Perl 5's DBI is the same Tim Bunce who's working on the Perl 6 DBI. (I, for one, think Tim's experiences may give him solid expertise.)

great code and great phrase ("smell of progress in the morning") =)

So after making the alternate proposal up above, I slapped together
a DBIx to do what I was talking about for perl 5

Leave a comment

Job hunting for programmers


Land the Tech Job You Love, Andy Lester's guide to job hunting for programmers and other technical professionals, is available in PDF, ePub and .mobi formats, all DRM-free, as well as good old-fashioned paper.