[Dbix-class] Incorrect SQL being generated after DBIC library upgrade

[Dami Laurent (PJ)]

Hi all,

I am responsible for those changes in -and/-or behaviour between 1.24
and 1.50. 

The point is: it was impossible to keep 1.24 behaviour on every detail,
because 1.24 had several internal inconsistencies, and also was
inconsistent with its own documentation. So understanding the old arcane
behaviour, finding out where it
differed from the doc, and deciding what to do was really a tough task.
Please read carefully the CHANGES Pod section in 1.50, which starts by
saying :

   Great care has been taken to preserve the I<published> behavior
   documented in previous versions in the 1.* family; however,
   some features that were previously undocumented, or behaved 
   differently from the documentation, had to be changed in order
   to clarify the semantics. Hence, client code that was relying
   on some dark areas of C<SQL::Abstract> v1.* 
   B<might behave differently> in v1.50.


If you want more details, also read the notes marked LDNOTE in the
source code. 

In particular :

- {-and/-or  => [...]} were indeed supported in older versions, but
meanwhile the 
  old doc always said :

   B<Important:> Note that the C<-modifier> goes
   B<INSIDE> the arrayref, as an extra first element. This will
   B<NOT> do what you think it might:

       priority => -and => [{'!=', 2}, {'!=', 1}]   # WRONG!

- nesting of -and / -or was implemented through a global variable, with
silly
  side-effects

           # LDNOTE : previous SQLA code for hashrefs was creating a
dirty
           # side-effect: the first hashref within an array would change
           # the global logic to 'AND'. So [ {cond1, cond2}, [cond3,
cond4] ]
           # was interpreted as "(cond1 AND cond2) OR (cond3 AND
cond4)", 
           # whereas it should be "(cond1 AND cond2) OR (cond3 OR
cond4)".


Best regards,

	Laurent Dami