X-Git-Url: http://git.shadowcat.co.uk/gitweb/gitweb.cgi?a=blobdiff_plain;f=lib%2FSQL%2FAbstract.pm;h=48a2f5b0810c89367f07f2d7e3baf71f09bf328d;hb=a3e3e6a18;hp=56bd63133101e4378461a926531943847bc1aaec;hpb=966200cc8a0d73449caac4beb3a7f3c60580b0de;p=dbsrgits%2FSQL-Abstract.git diff --git a/lib/SQL/Abstract.pm b/lib/SQL/Abstract.pm index 56bd631..48a2f5b 100644 --- a/lib/SQL/Abstract.pm +++ b/lib/SQL/Abstract.pm @@ -16,6 +16,11 @@ BEGIN { else { require mro; } + + *SQL::Abstract::_ENV_::DETECT_AUTOGENERATED_STRINGIFICATION = $ENV{SQLA_ISVALUE_IGNORE_AUTOGENERATED_STRINGIFICATION} + ? sub () { 0 } + : sub () { 1 } + ; } #====================================================================== @@ -98,8 +103,6 @@ sub is_plain_value ($) { # intersted in are much more limited than the fullblown thing, and # this is a very hot piece of code ( - # FIXME - DBI needs fixing to stringify regardless of DBD - # # simply using ->can('(""') can leave behind stub methods that # break actually using the overload later (see L, on sucess returns a B reference to the original supplied argument. +=over + +=item * Note + +The stringification overloading detection is rather advanced: it takes +into consideration not only the presence of a C<""> overload, but if that +fails also checks for enabled +L|overload/Magic Autogeneration>, based +on either C<0+> or C. + +Unfortunately testing in the field indicates that this +detection B<< may tickle a latent bug in perl versions before 5.018 >>, +but only when very large numbers of stringifying objects are involved. +At the time of writing ( Sep 2014 ) there is no clear explanation of +the direct cause, nor is there a manageably small test case that reliably +reproduces the problem. + +If you encounter any of the following exceptions in B - this module may be to blame: + + Operation "ne": no method found, + left argument in overloaded package , + right argument in overloaded package + +or perhaps even + + Stub found while resolving method "???" overloading """" in package + +If you fall victim to the above - please attempt to reduce the problem +to something that could be sent to the L +(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 +not being able to properly detect exotic forms of stringification). + +This notice and environment variable will be removed in a future version, +as soon as the underlying problem is found and a reliable workaround is +devised. + +=back + =head2 is_literal_value Determines if the supplied argument is a literal value as understood by this @@ -2632,7 +2683,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 => \[q/= date '2008-09-30' - ?::integer/, 10] ) This would create: @@ -2649,7 +2700,7 @@ L will simply pass it through intact. So if C is set to C the above example will look like: my %where = ( - date_column => \[q/= date '2008-09-30' - ?::integer/, [ dummy => 10 ]/] + date_column => \[q/= date '2008-09-30' - ?::integer/, [ dummy => 10 ]] ) Literal SQL is especially useful for nesting parenthesized clauses in the