Hack 24. Query Databases Dynamically Without SQL


Write Perl, not SQL.

SQL is a mini-language with its own tricks and traps. Embedded SQL is the bane of many programs, where readability and findability is a concern. Generated SQL isn't always the answer either, with all of the quoting rules and weird options.

In cases where you don't have a series of fully baked SQL statements you always runwhere query parameters and even result field names come from user requests, for examplelet SQL::Abstract do it for you.

The Hack

Create a new SQL::Abstract object, pass in some data, and go.

Suppose you have a reporting application with a nice interface that allows people to view any list of columns from a set of tables in any order with almost any constraint. Assuming a well-factored application, the model might have a method resembling:

use SQL::Abstract; sub get_select_sth {     my ($self, $table, $columns, $where) = @_;     my $sql           = SQL::Abstract->new( );     my ($stmt, @bins) = $sql->select( $table, $columns, $where );     my $sth           = $self->get_dbh( )->prepare( $stmt );     $sth->execute( );     return $sth; }

$table is a string containing the name of the table (or view, preferably) to query, $columns is an array reference of names of columns to view, and $where is a hash reference associating columns to values or ranges.

If a user wants to query the users table for login_name, last_accessed_on, and email_address columns for all users whose signup_date is newer than 20050101, the calling code might be equivalent to:

my $table   = 'users'; my $columns = [qw( login_name last_accessed_on email_address )]; my $where   = { signup_date => { '>=', '20050101' } }; my $sth     = $model->get_select_sth( $table, $columns, $where );

The returned $sth is a normal iterable DBI statement handle, suitable for passing to a templating system or other user interface view component. This is very useful for selecting only the interesting parts of a table or view.

Hacking the Hack

There's no reason you have to let users select the kind of information they want to view. Perhaps you have system administrators who should be able to see (and update) any non-key column in the users table, managers who should be able to see and update most personnel-related columns, and normal users who should only see demographic information.

You can use the same underlying model to fetch information from the databasejust add a layer over it to exclude requested columns that the particular user of the system shouldn't see. Assuming that you have an object representing the user type with a method that returns the allowed columns for a particular table, call restrict_columns( ) before get_select_sth( ):

sub restrict_columns {     my ($self, $user, $table, $columns) = @_;     my $user_columns                    = $user->get_columns_for( $table );     return [ grep { exists $user_columns->{ $_ } } ] @$columns; }

Instead of maintaining separate SQL queries for each type of user accessing the system, you can maintain a list somewhere of appropriate view and update columns for each type of user, reusing the query generator. If you keep the list of types and allowed columns in the database or in a configuration file somewhere, you have data-driven programming and an easy-to-maintain system.



Perl Hacks
Perl Hacks: Tips & Tools for Programming, Debugging, and Surviving
ISBN: 0596526741
EAN: 2147483647
Year: 2004
Pages: 141

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net