in reply to DBIx::Pretty (was DBI::Pretty)

I've seen this approach to "removing" SQL from code before. You're not actually achieving much.

  1. you still need to write/port the SQL to other databases, if you are doing a lot of queries this is a problem.
  2. and all your SQL ends up in one place which is a nightmare for management in larger programming projects; it needs to be closest to where it is being used and independant.
  3. You still are stuck if you want to represent complex ideas such as members that are lists, sets, etc.
  4. Every time you want to do a simple query you have to edit that central list!

Here's the real Perl code to do what you do in your POD, using Tangram:

# return an object representing the "remote" object, ie the
# one in the object store
my $remote_customer = $db->remote("Customer");

# get all customers whose name is like ?Wall
my (@objs) =
    $db->select( $remote_customer,
                 $remote_customer->{name}->like("?Wall") );

# set the first one's balance to 10000
$obj[0]->{balance} = 10000;
$db->store($obj[0]);

[download]

Other things:

I would change:

    croak "DBI::Pretty requires a valid DBI object"
      unless $dbi;

[download]

to:

    croak "DBI::Pretty requires a valid DBI object"
      unless (ref $dbi and $dbi->isa("DBI"));

[download]

Wouldn't it also be cleaner to write:

sub new($$;$) {
    my ($class, $dbi, $hash) = (@_);
    croak "DBI::Pretty requires a valid DBI object"
      unless $dbi;
    $hash ||= {};

[download]

instead of:

sub new {
    my $class = shift;
    my $dbi = shift;
    croak "DBI::Pretty requires a valid DBI object"
      unless $dbi;
    my $hash = shift || {};

[download]

Replies are listed 'Best First'.
Re: Re: DBI::Pretty
by Masem (Monsignor) on Jul 01, 2001 at 15:47 UTC
    Your points are quite valid, and by no means am I suggesting that this module would be the end-all to DBI programming.

    The thing that I was trying to do with this was (as indicated in the thread noted) to separate out SQL from programming logic as one tries to do with HTML and programming logic. Yes, I know SQL/logic are more closely tied, but I've found that once I've gotten most of the program logic down, I hardly touch the SQL from that point. SQL statements tend to be 'static' (regardless of placeholders), so isolating them once programming is done is not unreasonable.

    As for other SQL engines and the idea of lists or sets, all you are giving DBI::Pretty are plain text SQL statements and a DBI handler; as you probably know what you are doing with what database, any problems with SQL statements not carrying over is your own fault; DBI::Pretty isn't trying to recreate a standard DBI. And as long as you can write the SQL to handle sets or lists, there's no reason why this doesn't work with it. You'll still be needing to use placeholders and the like.

    I'm not offering DBI::Pretty as a placebo; I don't expect to see a "Use DBI::Pretty or die()" thread on PM anytime soon. But based on the indicated thread, there does seem to be a vested interest in cleaning SQL calls. Tangram is one approach as you've got above, though I've not used it myself; looking over the docs, it's more to rid the SQL-nature of database calls into a more OOP-type of way. Here, I assume that you still want to have SQL around, but not as embedded in the program as is typically done. What I believe DBI::Pretty offers is a way to develop SQL/DBI calls that are not only easier to read, but offer a way to genralize common SQL calls (eg "SELECT $fields FROM..." can be used assume the rest is the same with any number of combinations of $fields), as well as possibly helping to relieve maintainence nightmares. I have no expectations of where this might go; it was mostly built for curiosity's sake (and now I know how to use AUTOLOAD as well, which is a plus).

    Dr. Michael K. Neylon - mneylon-pm@masemware.com || "You've left the lens cap of your mind on again, Pinky" - The Brain
[reply]
      check out Class::DBI and Ima::DBI by Schwern, on CPAN. I think they'll do exactly what you want.
[reply]

In Section Code Catacombs