Forum OpenACS Development: ]project-open[ V4.0 on OpenACS 5.6: OpenACS Upgrade Issues

Request notifications


With some delay we have finally committed OpenACS 5.6 into the ]po[ CVS repository. In the next months we'll have to upgrade some 3.000 OpenACS instances running ]po[ at our customers, so we are now looking to eliminate _ANY_ error conditions that might come up. This is particularly important, because most updates will be performed by non-techies who are not capable of interpreting the upgrade error messages etc.

So we are now actually "forking" the OpenACS 5.6 code in order to introduce our changes. Maybe you want to include these changes in to OpenACS HEAD:

- acs-content-repository/sql/postgresql/upgrade/upgrade-5.2.0d16-5.2.0d17.sql:
Malte told me that this "select content_type__refresh_trigger (ct.object_type)" acutally never worked, so we have disabled it.

- ref-countries and ref-languages:
In our system there are already entries in acs_reference_repositories, so we need to remove these in the *-create.sql scripts.

- In several other packages we had to introduce checks if data already existed. For example, the 'ACSObject' service contract already exists in the default ]po[ database from incomplete installations many years ago apparently. So we have to change the "categories-init.sql" installation script to handle this condition.

Concerning an installation of ]po[ on top of an existing OpenACS istallation: We have tested this the last time some 2 years ago with OpenACS 5.4 or so. I don't expect any important issues with that, as we ALWAYS introduce changes from upgrade scripts into the create scripts. However, we usually don't test these updates, so that minor syntactic errors (forgotten ",", ...) may need to be fixed.


Let's be precise before I get slammed down again by Don for saying crap ;-).

The acs-content-repository/sql/postgresql/upgrade/upgrade-5.2.0d16-5.2.0d17.sql does not work if you have upgraded acs-kernel before (I think), to 5.6.0. If I remember correctly you would have to upgrade to 5.2 first and then continue onwards to 5.6. Therefore in my opinion it might make sense to remove the acs-content-repository/sql/postgresql/upgrade/upgrade-5.2.0d16-5.2.0d17.sql from the oacs-5-6 branch, as it will break upgrades from versions before 5.2.

This being said, we run our ]po[ installations purely by checking out the latest OpenACS release branch and the ]po[ HEAD version (as this was the only one so far being able to work with OpenACS > 5.1) and have had not many issues so far (although we use an old ]po[ dumpfile as a starting point and upgrade, instead of making a new install).

One more thing... Full text search needs ammending for PostgreSQL versions > 8.2. Not sure what exactly has to be done (still in the process of figuring this out), but you have been warned :-). This talks about intranet-search-pg package, not the OpenACS search package, which works fine.

Can you give any update about PO versions and OpenACS? I was able to install the package file you provided at sourceforge on top of OpenACS Debian squeeze version (5.5.1):

There were some issues I could fix, although the biggest problem seems to be PostgreSQL 8.4: there's no explicit type cast.

As I don't want to rewrite all queries from PO to use explicit types, I was wondering if I can upgrade using some other version file you have on sourceforge so I can avoid this issue.

Is there any Upgrade version I can use?

Hi Eduardo,

]po[ V4.0 has just come out in it's first "dev-1" version with OpenACS 5.6.0 as a base.

I'm now running ]po[ on a PG 8.4 database since a few days for personal development. I've fixed a number of queries particularly in the time sheet system (parts still unchanged since ACS 3.4...), but everything else seems to work.

You'd need to pull the code from CVS though, because we haven't yet released an "update installer" for the current version. The current HEAD is very stable already, we're using it with a major European bank and a few other customers in production...


Hi Frank,

Thank you for the answer. I was able to install and saw these same errors you said, but I thought you were already working on it. I guess I'll have to change some of the queries myself then. :) Maybe we could share query changes to be faster.

However, there's a HUGE issue with PostgreSQL 8.4. It's so big that I think it's just impossible to use it on production. Take a look at it here:

It seems like Victor Guerra has fixed it already, but I can't say for sure because we don't know how the fix was. So, we have the following problem:

- PostgreSQL 8.2 "disappeared" from almost every Linux distributions. The only way is to compile it now. I couldn't install PO on it also. I've even tried 8.2.22 and 8.2.13, and neither work.

- PostgreSQL 8.3 is still present and it doesn't have the index problems I told you, but we need to add explicit type casts. I couldn't install PO on it also.

- PostgreSQL 8.4 needs explicit type casts in some points and I was able to install it, but there's the performance problems.

I'm not even thinking about PostgreSQL 9 yet, because there were still a lot of changes, good and bad to our datamodel. So, the question is: what's the PostgreSQL target version to PO? Should we keep trying it on 8.4 or come back to other version?

P.S.: I don't know if I'm getting blind but I couldn't find PO CVS address. Would you mind to give me this information again?

Hi Eduardo,

> same errors

They are fixed in CVS "HEAD". Please see the instructions on w HEAD is pretty stable now, so there is little risk for you.

> HUGE issue

Not with ]project-open[ (I believe...). We don't use the permission system in the same way as dotLrn. Permission in ]po[ are mostly _calculated_ at runtime. We use OpenACS permissions just for storing basic configuration information. My development server has only 2700 entries in acs_permissions. Having said all this: We don't have many customers in production yet on 8.4., so there may still be some surprises.

> PostgreSQL 9

That will also be a major issue for us, going through several thousand SQL queries... A nightmare. I'm already thinking about a semiautomatic solution.


The real problem with PostgreSQL 8.2 is not that it "disappeared" from distros, but that it reached its end-of-life in dec 2011 (

An upgrade to PostgreSQL 9 is *no* OpenACS nightmare. We are using pg9.0 in production, the head version of openacs runs with (my changes from july this year) with 9.1, tested with kernel + xotcl-core, xowiki, xowf and the openacs packages required by xowiki.

-gustaf neumann


I'm sorry if I'm asking too many questions here. Please let me know if I should forward it to PO forums.

My system configuration wasn't working somehow, and now I've found the problem: the table im_dynfield_layout is empty.

I was following the isntructions trying to create Internal company and I got the following error:

Error with callback '_form_fill':

When I got to the code I saw that line 1114 in intranet-dynfield/tcl/intranet-dynfield-procs.tcl having the following operation:

db_foreach attributes $attributes_sql {

# Check if the elements as disabled in the layout page
if {$page_url_exists_p && "" == $page_url} { continue }

This query is making that object_type var is set to null value. I've dig into the SQL files and I couldn't find insert in default layouts for im_companies. Did I miss something?

I can also see this message in my /intranet-dynfield/ URL:

There are invalid DynFields in the system for the following object types.
These DynFields won't be shown.
im_company: default_bill_template_id
im_company: default_delnote_template_id
im_company: default_invoice_template_id
im_company: default_payment_days
im_company: default_payment_method_id
im_company: default_po_template_id
im_company: default_vat
im_invoice: canned_note_id
im_material: file_type_id
im_project: final_company
Please check these DynFields and make sure that every DynField has a "Pos-Y" value
by editing the DynField and specifying a value. You can use '0' as a default.

Can you give me any guidance on this?

Hi Eduardo,

Sorry, I've seen your questions only right now.
Is the issue still open?

In the mean time V4.0.4 has been released as the "official" V4.0 version, and PostgreSQL 8.4 is the default database both on Linux and on Windows.