Wade Pearce wrote:
Anyway, our server owner decided it was time to install the latest Debian hot fixes. Unknown to him (and undocumented by the hot fix), it proceeded to update Zope from 2.2 to 2.5.2 and Postgres from 6.5 to 7.2. Due to voluntary nature of our developers and the existence of legacy stuff in our website, we needed to keep these older versions running while a new website was built replacing our legacy stuff.
Luckily, the upgrade hasn't caused as much trouble as we thought it would. In fact, Zope and Postgres seem to have coped quite well with it (thanking the big guy upstairs for that one). We've just run into one problem.
Had your Zope been one version older, you might have had some bigger problems.
The current website uses a lot of <dtml-call "REQUEST.set...> calls to push database field values to the top of the memory pile. In the previous version, if a returned value from the database was an integer, the variable assigned that value in the REQUEST.set would also assume an integer datatype.
So, if "SELECT count(*) as total from table_1" was a Z SQL Method called in a DTML document and there was a <dtml-call "REQUEST.set('table_1_total',total)"> in the DTML document, then table_1_total would assume the datatype of integer.
The problem we have now is that in the above example, table_1_total is assuming the datatype of string, so in fact, table_1_total = '0' not table_1_total = 0.
This causes us problems all through the site, as any statement such as:
<dtml-if expr="table_1_total > 0" will always be true, because '0' > 0.
Now, is there a way to fix this or is it a design feature of the later versions of Zope/Python that requires a tightening of code?
I'm not sure why that is: don't deal with ZSQL enough to know. It might be ZSQL, it might be 'REQUEST.set', or it might be a symptom of the Postgres upgrade. You could check Zope changelogs if you really care, or do some experiments. (Do you get a string or an integer when you call the ZSQL method directly?) The easiest way is to rename your ZSQL method to something else and have it called by a Python script that does an 'int()' on the results. You can also do this wherever it is called. Or you could refactor to get rid of 'REQUEST.set' if that's the culprit. Even if it's not, doing a bunch of 'REQUEST.set's is usually unnecessary and considered bad form. --jcc -- "Code generators follow the 80/20 rule. They solve most of the problems, but not all of the problems. There are always features and edge cases that will need hand-coding. Even if code generation could build 100 percent of the application, there will still be an endless supply of boring meetings about feature design." (http://www.devx.com/java/editorial/15511)