Forum OpenACS Development: Re: FYI: Errors upgrading ]po[ from OpenACS 5.9.0 to 5.9.1

What makes you think that 5.10 requires the latest NaviServer?

You did not make an upgrade from 5.9.0 to 5.9.1, but from 5.7* to 5.9.1. It looks to me as if the po 5.9.0 was just a partial OpenACS 5.9.0, since apparently some upgrade scrips required for 5.9.0 were skipped - probably causing what you call "zombie items".

Glad, that 5.9.1 still works.


what makes you think

It uses try - catch, which is not in NaviServer 4.99.8 and ns_parseurl which also only appears considerably later. Then I stopped checking and went for 5.9.1, which already includes CSP (which is what I was looking for).


Yeah, something went wrong a long time ago. I'm glad that xowiki works, that was the most difficult one...


It uses try - catch, which is not in NaviServer 4.99.8 ...

"try" has nothing to do with NaviServer, it is part of Tcl 8.6 (released in 2013)

If for whatever reason you have to use Tcl 8.5, you can use the "try" package in tcllib for Tcl 8.5 upward compatibility.

all the best -g

Hi Frank, at this point I am wondering what prohibits using the latest Naviserver and the latest TCL version, as both have been around for some time.

Additionally, I am getting concerned about reliance on PG9. Do you migrate to oacs-5-9-1 CVS version, which according to the compatibility matrix supports PG11?

That move probably requires some changes in PO code, but while you are at it anyway .....



No problem to use the new NaviServer. It's just that ]po[ V5.0 still uses the 4.99.8, and I don't want to tell customers to do yet another upgrade.


We would have to fix TSearch2 for PG 10/11. That's not difficult, it's just another API. The "surface" between ]po[ and TSearch2 is not very large.
However, as with NaviServer, we will still be using CentOS 7 with PG 9 for a while, so from this side there isn't much pressure to do the migration.

I'd estimate half a day to a day for this. We could do this as part of merging your changes into ]po[ "vanilla"?


The following is just for info.

This is ]project-open[ version running on Windows-OpenACS June 2020 version (with the latest of everything).

Have a wonderful Sunday,

Hi Maurizio,

do you have a list of things you needed to do in order to get this working?

Did you use the ]project-open[ dumpfile for this to get started or did you do a fresh install of ]project-open[ on top of your windows system?

I want to update the ]project-open[ docker containers to the latest version, as I do follow your strategy (upgrade to latest packages on a regular basis). Additionally, I'm not entirely sure when e.g. PG9 runs out of maintenance.

Looking forward to your pointers (and if you say "there isn't much to worry about" even the better 😊).


Hello Malte and Frank,
I downloaded around the end of June (29th) the official ]po[ Windows distribution. Then from there I got the DB and the packages.
I put the packages on top of my distribution and used the above DB as starting point.
I run some few upgrades/updates.
To replicate what I did you can get:
1. my distribution:
Once installed, in /naviserver/software/ you can get the naviserver sources I use
2. some material:
containing the modified ]po[ packages and DB.

It is rough material, but I hope it helps.


We would have to fix TSearch2 for PG 10/11.

What do you want to fix? we use it with these versions (with oacs-5-10, but i do not think we had to fix something)


As far as I know, for Tsearch2 in the ]pproject-open[ codebase, the only required modification is to change all calls to "to_tsquery('default', x)" to "to_tsquery(x)"
Tha's it and that's all. A single edit operation.


Hi Maurizio,

Thanks for posting! I knew it would be something like that, but I didn't even look yet ...

]po[ copies the strings to be indexed into a separate table and applies the TSearch2 full-text index on one column of that table. ..


You're welcome Frank.

It's a matter of strategy.

A first strategy corresponds in doing the updates/upgrades every now and then, say every X years. By so doing the number of changes that have to be taken into account is quite considerable. And you have to test all these changes.

Another strategy, the one I've been using for OpenACS, is to always keep up with the developments of the various components/libraries and always make sure that everything works. By so doing, the number of changes that have to be taken into account every single update is very limited (1 or at most 2 at a time). This reduces dramatically the time required to solve the issues related with the change(s).

I might be wrong, but I believe that at the end of the day, the second strategy is cheaper.


Hi Maurizio,

yes, you were right. I only had to remove duplications from tsearch2-driver which made it into intranet-search-pg and ammend the queries as per your instructions. Well.. and load an updated im_search_update function into postgresql before running any update (as there are triggers on cr_items which fire with normal openacs upgrades).

(removed ]project-open[ code..  wrong place )