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

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...

Cheers,
Frank

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: http://openacs.org/forums/message-view?message_id=3804765

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 whttp://www.project-open.org/documentation/developers_cvs_checkout. 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.

Cheers!
Frank

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 (http://www.postgresql.org/support/versioning/).

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

Frank,

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.

Cheers!
Frank