Hi Dave,
On Fri, Jan 31, 2014 at 12:01 AM, Dave <ledger...@1001111.com> wrote:
> On 01/30/2014 12:02 PM, Erik Huelsmann wrote:
> > That is: 1.3.36 doesn't have this issue on those versions.
> > You could use PostgreSQL 9.1 or higher. The issue doesn't exist on
> those versions.
>
>
>
You are not happy with my production environment are you :)
>
Sorry about my terse reactions earlier today; wasn't near a good keyboard
at the time. Just got back to responding less tersely when your response
came in and I decided to respond to this mail instead of your earlier ones.
It's not that we don't like your production environment, however, you said
you were not ready to move to anything but a stable release. My response
was to help you with a stable combination of LedgerSMB and PostgreSQL.
We do want to support all current (ie non-EOL-ed) versions of PostgreSQL.
However, we certainly could use some help here: there are a lot of
combinations and a lot of tests to be run. Unfortunately, many of the areas
that we call "old code" - areas of code inherited from 1.2 and all the way
back to SQL Ledger - are tough territory to build automated tests for.
Meaning that a lot of testing needs to be done by hand.
We're sorry you ran into a regression. We have -fortunately- seen very few
regressions, meaning that the 1.3.x series are nearly completely
monotonically increasing stability [fixes for issues found in 1.2 and
earlier as well, or caused during development of 1.3, but found after the
release of 1.3.0].
> I'm not happy with your SQL :)
>
I'm definitely *not* claiming the SQL was alright and should stay as it is.
As a matter of fact: it's already fixed in our stable branch (1.3) *and* we
have a release ready to fix the issue. That release would have been out
already if it wasn't for the fact that testing and regression fixing hadn't
been completed yet. At this point 1.3.37-rc3 is production ready, just
waiting for Chinese New Year to blow over to get released.
> The real problem is bad SQL (if a column is not in an aggregate it must be
> in the group by clause)
>
Yup. No excuse. It's broken, but wasn't timely detected because newer
versions of postgresql are less strict about it (if you have all fields of
the primary key in the group by, it's satisfied - versions 9.1 and up).
> and that the the tarball and Centos 6 rpm for 1.3.36 are broken :(
> Postgres 8.4 is the version on the Centos/RHEL 6.4 and 6.5 RPMs
>
Please don't take my statement as putting you off. We still want to see all
issues you run into reported. We're still committed to fixing the issues
you're finding. Even on this combination of versions. My response was
mainly to get you a direction to work with as quickly as possible, as you
were running into production issues. However, we could use some help from
people like you who run with these setups as their default (most devs
develop on newer PostgreSQL versions) to do release candidate testing. It
helps trip us up on this kind of issue.
> Appending ' a.crdate,' to lines 971 and 1019 in LedgerSMB/AA.pm
> fixes the issue and off to TST and STG it goes.
>
Sounds like a solution. Exactly this is (one of) the fix(es) in 1.3.37.
>
> Your code was wonderful to work on, I was in and out in less than 5
> minutes, thank you.
>
> [root@web001 LedgerSMB]# grep -n a.crdate AA.pm
> 941 SELECT a.id, a.invnumber, a.ordnumber, a.transdate,
> a.crdate,
> 979 SELECT a.id, a.invnumber, a.ordnumber, a.transdate,
> a.crdate,
> [root@web001 LedgerSMB]# vi AA.pm
> [root@web001 LedgerSMB]# grep -n a.crdate AA.pm
> 941: SELECT a.id, a.invnumber, a.ordnumber, a.transdate,
> a.crdate,
> 971: GROUP BY a.id, a.invnumber, a.ordnumber, a.transdate,
> a.duedate, a.netamount, a.crdate,
> 979: SELECT a.id, a.invnumber, a.ordnumber, a.transdate,
> a.crdate,
> 1019: GROUP BY a.id, a.invnumber, a.ordnumber,
> a.transdate, a.crdate,
>
> Yes in as root, my bad
>
:-) We all have our moments, apparently.
Hope that explains our position better.
--
Bye,
Erik.
http://efficito.com -- Hosted accounting and ERP.
Robust and Flexible. No vendor lock-in.
------------------------------------------------------------------------------
WatchGuard Dimension instantly turns raw network data into actionable
security intelligence. It gives you real-time visual feedback on key
security issues and trends. Skip the complicated setup - simply import
a virtual appliance and go from zero to informed in seconds.
http://pubads.g.doubleclick.net/gampad/clk?id=123612991&iu=/4140/ostg.clktrk
_______________________________________________
Ledger-smb-users mailing list
Ledger-smb-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ledger-smb-users
