Well, better late than never. Enjoy.

Not all queries are made to request the data; you will also want to be able to update, delete, and insert data.

So the query language that DBIx::Perlish implements also provides db_update, db_delete, and db_insert functions.

The db_update and db_delete functions are in fact very similar to db_fetch, with which you are already familiar.

Let’s start with db_update:

db_update {
   my $u : users;
   $u->id == 42;  # filter

   $u->first_name = "Ford";
   $u->last_name  = "Prefect";
};

You can see that a query sub that db_update takes has all the same elements as a query sub taken by db_fetch, with an addition of an assignment to update column values. Quite natural, eh?

One thing to remember is that you cannot use a return statement with db_update - it has no meaning!

It can become quite tedious to write all the individual assignments if the number of columns to be updated is not small. Luckily, there is a shortcut:

db_update {
   my $u : users;
   $u->id == 42;  # filter

   $u = {
      first_name => "Ford",
      last_name  => "Prefect",
      age        => $u->age + 1,
   };
};

That is, you can just use hash reference syntax.

You might have noticed that in the last example an expression involving age column was used to update it. That works as you would expect it will.

Using db_delete is equally simple.

db_delete {
   users->id < 20;
};

Using return did not make sense with db_update. This is also the case with db_delete.

Moreover, assignments which you were using with db_update make no sense neither with db_delete nor with db_fetch.

Another thing you would want to do, inserting the data into a table, is done differently. Unlike updates and deletes, inserts do not require a query language since they are so simple.

So if you want to insert a row into a table, you do it with a simple hashref:

db_insert 'users', {
   id         => 42,
   first_name => "Ford",
   last_name  => "Prefect",
};

Nothing fancy here.

To be continued.

First post, Getting rid of SQL from Perl code
Second post, A walk through an example
Third post, Many happy returns

Coming back to the original example,

my $uid = 42;
my @r = db_fetch {
    my $u : users;

    $u->groups_id == groups->id;
    $u->id == $uid;
};

One more thing to note about this, before moving on: when you specify more than one filtering expression, there is an implicit and between them - so that only those rows which satisfy all expressions will match.

What more the language does to be useful?

Needless to say, all the normal binary operators are supported, so your expectation that arithmetics work is not destroyed:

my $uid = 40;
my @r = db_fetch {
    users->id == $uid + 2;
}

String concatenation also works, including interpolation:

my @r = db_fetch {
    my $u : users;
    return "$u->first_name $u->last_name";
}

This last example shows that DBIx::Perlish interpolates columns represented as method calls in a string. This would normally not work in a “normal” Perl.

If you are paying attention, you can see that there is another new thing in the last example, namely, the presence of the return statement.

If there is no return statement in the query sub, all columns will be returned; it is completely analogous to SQL’s SELECT * statement.

So you use the return statement when you want to control what is returned by the query. In this case it will be the concatenation of the column first_name, a space character, and the column last_name from the table users.

How the query result is returned?

There are four possibilities; which one is chosen depends on what the return statement, if any, specifies, and what context (list or scalar) the db_fetch is being used in.

If you call db_fetch in a scalar context, you indicate that you are only interested in one row of the resulting data set. Using list context you indicate that you want all rows back.

So the context controls how many rows you want back.

On the other hand, if you specify a return statement with precisely one value, you indicate that you are only interested in one particular column of the resulting data set. The absence of the return statement or a return statement with a list of values indicates that you want several columns back.

So the return statement controls how many columns within a row you want back.

Combining two possibilities for rows with two possibilities for columns, you get four possible combinations.

Let’s illustrate these possibilities with examples.

1. Scalar context, single-value return:

my $name = db_fetch { return user->name }; print “The name of some user is $name\n”;

You get one row with one column back - a single scalar value.

1. List context, single-value return:

my @names = db_fetch { return user->name }; print “The names of all users are @names\n”;

You get an array with column values back.

1. Scalar context, more than one column returned:

my $u = db_fetch { return user->id, user->name }; print “The name of a user with id $u->{id} is $u->{name}\n”;

Please note that you get a hash reference back with the keys being the names of the columns returned.

1. Finally, the most common case of the list context with more than one column returned:

my @u = db_fetch { return user->id, user->name }; for my $u (@u) { print “$u->{id}:\t$u->{name}\n”; }

Observe that you get an array of hash references back.

Now, you might ask, what will be the names of the columns in a case like this:

my @r = db_fetch {
    my $u : users;
    return $u->id, "$u->first_name $u->last_name";
}

One of the columns is obviously “id”, but what about the other one? How do you refer to it in the result you’ve got?

The answer is - it is database-dependent and can be pretty much anything. So you ask the next question: “can I control that?”.

Yes, you can, by prepending the offending nameless column with the name you want for it in the return statement:

my @r = db_fetch {
    my $u : users;
    return $u->id, full_name => "$u->first_name $u->last_name";
}

More in the next post.

First post, Getting rid of SQL from Perl code
Second post, A walk through an example

Let us go through the example of DBIx::Perlish’s non-SQL language which I concluded the last post with:

my $uid = 42;
my @r = db_fetch {
    my $u : users;

    $u->groups_id == groups->id;
    $u->id == $uid;
};

I hope it is obvious to you what that snippet does, but let’s go through it anyway.

First thing to note that it deals with two database tables, users and groups. The snippet also illustrates that there are two ways to refer to a table - explicitly by name, as is done with groups, and via aliasing a table to a local variable using Perl attribute syntax. This latter method is preferable when you have to refer to a table more than once or twice. This method is also the only one with which you can make self-joins, but I’ll talk about it later.

So the above snippet could have been written as

my $uid = 42;
my @r = db_fetch {
    users->groups_id == groups->id;
    users->id == $uid;
};

as well as

my $uid = 42;
my @r = db_fetch {
    my $u : users;
    my $g : groups;

    $u->groups_id == $g->id;
    $u->id == $uid;
};

There are more things to pay attention to in the example.

You refer to the individual columns using Perl method call syntax. Since it is common to use accessor methods with Perl objects in order to get or set their properties, it does not require a stretch of imagination to see what $u->groups_id means.

The declarative semantics of the language is apparent in how you specify what results you want back from the query: individual comparison expressions are used as filters to limit an unconstrained result.

Let’s look at a simpler example:

my @r = db_fetch {
   my $u : users;
}

This will get you all rows from the users table. If you only want users with an id over a hundred, you would write:

my @r = db_fetch {
   users->id > 100;
}

If you were operating with a normal Perl array instead of a DB table, you would probably do the same filtering in one of two ways, a more familiar imperative one:

my @r;
for my $u (@users) {
   push @r, $u if $u->{id} > 100;
}

or a shorter declarative one, using grep:

my @r = grep { $_->{id} > 100 } @users;

So how the query language is used resembles declarative grep more than imperative for. But it is not news to you - after all, SQL does precisely the same!

More to follow.

Database handling in your program consists of queries and “everything else”.

DBI makes handling of the “everything else” part easy in Perl. It presents a unified interface to deal with a lot (although not all) idiosyncrasies of various numerous RDBMSes.

But mostly, when doing DB programming, you deal with queries. Which DBI does not help you much with.

Which are done using SQL.

SELECT * FROM users,groups
  WHERE
      users.groups_id = groups.id AND
      users.id = 42;

Which is a domain-specific language, from your point of view as a Perl programmer.

DSLs are all the rage nowadays, and I won’t dispute their advantages and usefulness.

But SQL is a very large DSL, as they go.

You are a smart programmer, so you learned SQL. You might even appreciate the fact that it is a declarative language, not unlike Prolog, which definitely adds a bit of excitement to the mundane task of writing your queries.

But every time you are writing Perl code that works with databases you need to constantly switch mental gears between Perl, the language you like (otherwise you would not be reading this), and SQL, the language very different from Perl. This is taxing. It costs you in lost productivity.

Even if you clearly separate in your code (and you should) those parts dealing with DB handling and those that are not, you still need to write those queries, and to switch languages back and forth.

At best, SQL in your Perl code severely disrupts the code flow by virtue of being a different language and thus looking very different from Perl.

my $r = $dbh->selectall_arrayref(
   "SELECT * FROM users, groups
    WHERE
      users.groups_id = groups.id AND
      users.id = ?",
   {Slice=>{}}, 42);

So you clearly have a problem that needs a solution.

One of the possible solutions is to use an object-relational mapper module such as Class::DBI, or DBIx::Class, or Jifty::DBI.

Such solutions have their merits. There are many arguments in favour of them. There are also arguments against them. I am not going to discuss them any further here, I would only like to point out that even if you use an object-relational mapper, you still cannot completely avoid writing SQL: sometimes because you need to construct a query that your mapper of choice does not support through its abstraction, and sometimes for efficiency reasons; the majority of the existing mappers do not deal well with collections, and provide you with shims to add your custom SQL code in strategic places.

Another solution, the solution which I am trying to sell you is to try to get away from using SQL as a domain-specific language in your Perl code altogether.

This involves creating yet another domain-specific language specifically for doing database queries with a (nice for Perl programmers) distinction that it actually looks very much like Perl. In fact, syntactically it is a valid Perl, altough semantically it is still a declarative language suitable for making relational database queries.

my $uid = 42;
my @r = db_fetch {
    my $u : users;

    $u->groups_id == groups->id;
    $u->id == $uid;
};

More on this in a future post.