- update to 1.72

* lots of changes, see Changes

OBS-URL: https://build.opensuse.org/package/show/devel:languages:perl/perl-SQL-Abstract?expand=0&rev=5

SQL-Abstract-1.60.tar.bz2

@@ -1,3 +0,0 @@
-version https://git-lfs.github.com/spec/v1
-oid sha256:bd32cb5f22330eb493c0740e1031d21e670025a495486f956de72b2be5c1fd00
-size 54604

SQL-Abstract-1.72.tar.gz

@@ -0,0 +1,3 @@
+version https://git-lfs.github.com/spec/v1
+oid sha256:7902abc8c5f4c5f9bc9bd2ffd0a2d4c98c55b5a1bde80d8b0b3a94ff41f94b89
+size 88235

perl-SQL-Abstract.changes

@@ -1,3 +1,9 @@
+-------------------------------------------------------------------
+Thu Mar 31 08:30:28 UTC 2011 - coolo@novell.com
+
+- update to 1.72
+  * lots of changes, see Changes
+
 -------------------------------------------------------------------
 Wed Dec  1 10:23:00 UTC 2010 - coolo@novell.com
 

perl-SQL-Abstract.spec

@@ -1,7 +1,7 @@
 #
-# spec file for package perl-SQL-Abstract (Version 1.60)
+# spec file for package perl-SQL-Abstract (Version 1.72)
 #
-# Copyright (c) 2009 SUSE LINUX Products GmbH, Nuernberg, Germany.
+# 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
@@ -15,53 +15,162 @@
 # Please submit bugfixes or comments via http://bugs.opensuse.org/
 #
 
-# norootforbuild
-
 Name:           perl-SQL-Abstract
-%define cpan_name %( echo %{name} | %{__sed} -e 's,perl-,,' )
+Version:        1.72
-Summary:        Generate SQL from Perl data structures
-Version:        1.60
 Release:        1
-License:        Artistic
+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
-URL:            http://search.cpan.org/dist/SQL-Abstract
+#Source:         http://www.cpan.org/authors/id/F/FR/FREW/SQL-Abstract-%{version}.tar.gz
-Source:         %{cpan_name}-%{version}.tar.bz2
+Source:         %{cpan_name}-%{version}.tar.gz
+BuildArch:      noarch
 BuildRoot:      %{_tmppath}/%{name}-%{version}-build
-%{perl_requires}
 BuildRequires:  perl
 BuildRequires:  perl-macros
-BuildRequires:  perl(Test::Pod) >= 1.14
+BuildRequires:  perl(Class::Accessor::Grouped) >= 0.10002
-BuildRequires:  perl(Test::Pod::Coverage) >= 1.04
+BuildRequires:  perl(Getopt::Long::Descriptive) >= 0.086
-BuildRequires:  perl(Pod::Coverage) >= 0.19
+BuildRequires:  perl(Hash::Merge) >= 0.12
-BuildRequires:  perl(Test::Builder)
-BuildRequires:  perl(Test::Deep)
-BuildRequires:  perl(Test::More)
-BuildRequires:  perl(Test::Exception)
-BuildRequires:  perl(Test::Warn)
-BuildRequires:  perl(Clone) >= 0.31
 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 DBIx::Abstract. However, in using
+This module was inspired by the excellent the DBIx::Abstract manpage.
-that module I found that what I really wanted to do was generate SQL, but
+However, in using that module I found that what I really wanted to do was
-still retain complete control over my statement handles and use the DBI
+generate SQL, but still retain complete control over my statement handles
-interface. So, I set out to create an abstract SQL generation module.
+and use the DBI interface. So, I set out to create an abstract SQL
+generation module.
 
- Author:
+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.
 
-	Laurent Dami, <laurent.dami AT etat geneve ch>
+To begin with, an SQL INSERT is as easy as just specifying a hash of
-	Norbert Buchmuller <norbi@nix.hu>
+'key=value' pairs:
-	Peter Rabbitson <ribasushi@cpan.org>
+
+    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
-SQLATEST_TESTER=1 TEST_POD=1 perl Makefile.PL OPTIMIZE="$RPM_OPT_FLAGS -Wall"
+%{__perl} Makefile.PL INSTALLDIRS=vendor
-%{__make}
+%{__make} %{?_smp_mflags}
 
 %check
 %{__make} test
@@ -72,12 +181,10 @@ SQLATEST_TESTER=1 TEST_POD=1 perl Makefile.PL OPTIMIZE="$RPM_OPT_FLAGS -Wall"
 %perl_gen_filelist
 
 %clean
-# clean up the hard disc after build
+%{__rm} -rf %{buildroot}
-%{__rm} -rf $RPM_BUILD_ROOT
 
 %files -f %{name}.files
-%defattr(-,root,root)
+%defattr(644,root,root,755)
 %doc Changes
 
 %changelog
-