Henning,
thanks for sorting this out. I was also very confused about the
offset/limit-handling some time ago, and I thought "ok, just don't touch
this stuff".
Sorry I am too busy at the moment to help testing but I hope this will
change soon.
Thomas
> Folks,
>
> while I was using a blind eye to look at the mess that the LIMIT /
> OFFSET generation has turned into, the last patch from Augustin was
> the straw that broke the camels' back. Or, to be literal, broke the
> LIMIT / OFFSET generation for everything else but DB2. E.g. PostgreSQL.
>
> Which upsets me, because I use PostgreSQL. However, I didn't use LIMIT
> until about an hour ago.
>
> At some point, one has to take a step back, look at what has been done
> and ask oneself "is this really what I intended to do". Three
> different places in the already much too large BasePeer class where
> limits are checked in different ways; Criteria manipulation just to
> satisfy a single caller of createQueryString, patch over patch over
> patch just to get this somehow to compile.
>
> My stomach couldn't take this any longer (and I need a working OFFSET
> LIMIT for PostgreSQL and I would not touch this mess with a 3 metre
> pole).
>
> So I ripped everything out, rewrote it into a helper class and put it
> back in. Cleaned up the logic and everything. It still passes the unit
> tests (which is a good sign). And there are a lot of the invariants
> removed. Why do we need "supportsNativeOffset" and
> "supportsNativeLimit" when e.g. Oracle and DB2 allows this (by using a
> subquery) but return false/false for the supportsNativeLimit/Offset
> (DB2) or true/false (Oracle)?
>
> All of this stuff _needs_ testing. Sorry Scott. We will need an RC2.
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
