8
0
Files
perl-SQL-Abstract/perl-SQL-Abstract.spec

191 lines
6.5 KiB
RPMSpec
Raw Normal View History

#
# spec file for package perl-SQL-Abstract (Version 1.72)
#
# Copyright (c) 2010 SUSE LINUX Products GmbH, Nuernberg, Germany.
#
# All modifications and additions to the file contributed by third parties
# remain the property of their copyright owners, unless otherwise agreed
# upon. The license for this file, and modifications and additions to the
# file, is the same license as for the pristine package itself (unless the
# license for the pristine package is not an Open Source License, in which
# case the license is the MIT License). An "Open Source License" is a
# license that conforms to the Open Source Definition (Version 1.9)
# published by the Open Source Initiative.
# Please submit bugfixes or comments via http://bugs.opensuse.org/
#
Name: perl-SQL-Abstract
Version: 1.72
Release: 1
License: GPL+ or Artistic
%define cpan_name SQL-Abstract
Summary: Generate SQL from Perl data structures
Url: http://search.cpan.org/dist/SQL-Abstract/
Group: Development/Libraries/Perl
#Source: http://www.cpan.org/authors/id/F/FR/FREW/SQL-Abstract-%{version}.tar.gz
Source: %{cpan_name}-%{version}.tar.gz
BuildArch: noarch
BuildRoot: %{_tmppath}/%{name}-%{version}-build
BuildRequires: perl
BuildRequires: perl-macros
BuildRequires: perl(Class::Accessor::Grouped) >= 0.10002
BuildRequires: perl(Getopt::Long::Descriptive) >= 0.086
BuildRequires: perl(Hash::Merge) >= 0.12
BuildRequires: perl(List::Util)
BuildRequires: perl(Scalar::Util)
BuildRequires: perl(Test::Deep) >= 0.106
BuildRequires: perl(Test::Exception)
BuildRequires: perl(Test::Warn)
Requires: perl(Class::Accessor::Grouped) >= 0.10002
Requires: perl(Getopt::Long::Descriptive) >= 0.086
Requires: perl(Hash::Merge) >= 0.12
Requires: perl(List::Util)
Requires: perl(Scalar::Util)
%{perl_requires}
%description
This module was inspired by the excellent the DBIx::Abstract manpage.
However, in using that module I found that what I really wanted to do was
generate SQL, but still retain complete control over my statement handles
and use the DBI interface. So, I set out to create an abstract SQL
generation module.
While based on the concepts used by the DBIx::Abstract manpage, there are
several important differences, especially when it comes to WHERE clauses. I
have modified the concepts used to make the SQL easier to generate from
Perl data structures and, IMO, more intuitive. The underlying idea is for
this module to do what you mean, based on the data structures you provide
it. The big advantage is that you don't have to modify your code every time
your data changes, as this module figures it out.
To begin with, an SQL INSERT is as easy as just specifying a hash of
'key=value' pairs:
my %data = (
name => 'Jimbo Bobson',
phone => '123-456-7890',
address => '42 Sister Lane',
city => 'St. Louis',
state => 'Louisiana',
);
The SQL can then be generated with this:
my($stmt, @bind) = $sql->insert('people', \%data);
Which would give you something like this:
$stmt = "INSERT INTO people
(address, city, name, phone, state)
VALUES (?, ?, ?, ?, ?)";
@bind = ('42 Sister Lane', 'St. Louis', 'Jimbo Bobson',
'123-456-7890', 'Louisiana');
These are then used directly in your DBI code:
my $sth = $dbh->prepare($stmt);
$sth->execute(@bind);
Inserting and Updating Arrays
If your database has array types (like for example Postgres), activate
the special option 'array_datatypes => 1' when creating the
'SQL::Abstract' object. Then you may use an arrayref to insert and
update database array types:
my $sql = SQL::Abstract->new(array_datatypes => 1);
my %data = (
planets => [qw/Mercury Venus Earth Mars/]
);
my($stmt, @bind) = $sql->insert('solar_system', \%data);
This results in:
$stmt = "INSERT INTO solar_system (planets) VALUES (?)"
@bind = (['Mercury', 'Venus', 'Earth', 'Mars']);
Inserting and Updating SQL
In order to apply SQL functions to elements of your '%data' you may
specify a reference to an arrayref for the given hash value. For
example, if you need to execute the Oracle 'to_date' function on a
value, you can say something like this:
my %data = (
name => 'Bill',
date_entered => \["to_date(?,'MM/DD/YYYY')", "03/02/2003"],
);
The first value in the array is the actual SQL. Any other values are
optional and would be included in the bind values array. This gives
you:
my($stmt, @bind) = $sql->insert('people', \%data);
$stmt = "INSERT INTO people (name, date_entered)
VALUES (?, to_date(?,'MM/DD/YYYY'))";
@bind = ('Bill', '03/02/2003');
An UPDATE is just as easy, all you change is the name of the function:
my($stmt, @bind) = $sql->update('people', \%data);
Notice that your '%data' isn't touched; the module will generate the
appropriately quirky SQL for you automatically. Usually you'll want to
specify a WHERE clause for your UPDATE, though, which is where handling
'%where' hashes comes in handy...
Complex where statements
This module can generate pretty complicated WHERE statements easily.
For example, simple 'key=value' pairs are taken to mean equality, and
if you want to see if a field is within a set of values, you can use an
arrayref. Let's say we wanted to SELECT some data based on this
criteria:
my %where = (
requestor => 'inna',
worker => ['nwiger', 'rcwe', 'sfz'],
status => { '!=', 'completed' }
);
my($stmt, @bind) = $sql->select('tickets', '*', \%where);
The above would give you something like this:
$stmt = "SELECT * FROM tickets WHERE
( requestor = ? ) AND ( status != ? )
AND ( worker = ? OR worker = ? OR worker = ? )";
@bind = ('inna', 'completed', 'nwiger', 'rcwe', 'sfz');
Which you could then use in DBI code like so:
my $sth = $dbh->prepare($stmt);
$sth->execute(@bind);
Easy, eh?
%prep
%setup -q -n %{cpan_name}-%{version}
%build
%{__perl} Makefile.PL INSTALLDIRS=vendor
%{__make} %{?_smp_mflags}
%check
%{__make} test
%install
%perl_make_install
%perl_process_packlist
%perl_gen_filelist
%clean
%{__rm} -rf %{buildroot}
%files -f %{name}.files
%defattr(644,root,root,755)
%doc Changes
%changelog