Link fixes (no other changes)

[scpubgit/Q-Branch.git] / lib / SQL / Abstract.pm

diff --git a/lib/SQL/Abstract.pm b/lib/SQL/Abstract.pm
index 08f6011..692816f 100644 (file)
--- a/lib/SQL/Abstract.pm
+++ b/lib/SQL/Abstract.pm
@@ -497,9 +497,15 @@ sub _recurse_where {
 
   my ($sql, @bind) =  $self->$method($where, $logic);
 
-  # DBIx::Class directly calls _recurse_where in scalar context, so
-  # we must implement it, even if not in the official API
-  return wantarray ? ($sql, @bind) : $sql;
+  # DBIx::Class used to call _recurse_where in scalar context
+  # something else might too...
+  if (wantarray) {
+    return ($sql, @bind);
+  }
+  else {
+    belch "Calling _recurse_where in scalar context is deprecated and will go away before 2.0";
+    return $sql;
+  }
 }
 
 
@@ -1718,7 +1724,7 @@ say something like this:
 
     my %data = (
         name => 'Bill',
-        date_entered => \["to_date(?,'MM/DD/YYYY')", "03/02/2003"],
+        date_entered => \[ "to_date(?,'MM/DD/YYYY')", "03/02/2003" ],
     );
 
 The first value in the array is the actual SQL. Any other values are
@@ -1919,7 +1925,7 @@ are or are not included. You could wrap that above C<for> loop in a simple
 sub called C<bind_fields()> or something and reuse it repeatedly. You still
 get a layer of abstraction over manual SQL specification.
 
-Note that if you set L</bindtype> to C<columns>, the C<\[$sql, @bind]>
+Note that if you set L</bindtype> to C<columns>, the C<\[ $sql, @bind ]>
 construct (see L</Literal SQL with placeholders and bind values (subqueries)>)
 will expect the bind values in this format.
 
@@ -2190,7 +2196,7 @@ or perhaps even
 
 If you fall victim to the above - please attempt to reduce the problem
 to something that could be sent to the L<SQL::Abstract developers
-|DBIx::Class/GETTING_HELP/SUPPORT>
+|DBIx::Class/GETTING HELP/SUPPORT>
 (either publicly or privately). As a workaround in the meantime you can
 set C<$ENV{SQLA_ISVALUE_IGNORE_AUTOGENERATED_STRINGIFICATION}> to a true
 value, which will most likely eliminate your problem (at the expense of
@@ -2683,7 +2689,7 @@ not so common, but perfectly legal Perl). For example, to find a date
 in Postgres you can use something like this:
 
     my %where = (
-       date_column => \[q/= date '2008-09-30' - ?::integer/, 10/]
+       date_column => \[ "= date '2008-09-30' - ?::integer", 10 ]
     )
 
 This would create:
@@ -2692,15 +2698,16 @@ This would create:
     @bind = ('10');
 
 Note that you must pass the bind values in the same format as they are returned
-by L</where>. That means that if you set L</bindtype> to C<columns>, you must
-provide the bind values in the C<< [ column_meta => value ] >> format, where
-C<column_meta> is an opaque scalar value; most commonly the column name, but
-you can use any scalar value (including references and blessed references),
-L<SQL::Abstract> will simply pass it through intact. So if C<bindtype> is set
-to C<columns> the above example will look like:
+by L<where|/where(\%where, \@order)>. This means that if you set L</bindtype>
+to C<columns>, you must provide the bind values in the
+C<< [ column_meta => value ] >> format, where C<column_meta> is an opaque
+scalar value; most commonly the column name, but you can use any scalar value
+(including references and blessed references), L<SQL::Abstract> will simply
+pass it through intact. So if C<bindtype> is set to C<columns> the above
+example will look like:
 
     my %where = (
-       date_column => \[q/= date '2008-09-30' - ?::integer/, [ dummy => 10 ]/]
+       date_column => \[ "= date '2008-09-30' - ?::integer", [ {} => 10 ] ]
     )
 
 Literal SQL is especially useful for nesting parenthesized clauses in the
@@ -3091,7 +3098,7 @@ The main changes are :
 
 =item *
 
-support for literal SQL through the C<< \ [$sql, bind] >> syntax.
+support for literal SQL through the C<< \ [ $sql, @bind ] >> syntax.
 
 =item *