Re: can't search on transactions

Hi Dave,

On Fri, Jan 31, 2014 at 12:01 AM, Dave <..hidden..> 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.