Forum OpenACS Q&A: Compatibility matrix and OpenACS 5.7
There are no versions of Tcl, PostgreSQL and Oracle stated as being compatible. It seems to suggest that OpenACS 5.7 might with PostgreSQL 8.1 (or even 8.0) and Tcl 8.4. Is this something I should chance (before updating PostgreSQL to a later version)?
OpenACS 5.7 Requires Postgresql 8.3 or higher.
I am upgraded two 5.2 sites recently to 5.7 with no problems.
Basically dump the database. Then import into Postgresql 8.3 database and then update your code to OpenACS 5.7 and start it up.
You should visit /acs-admin/apm/ and click "Install Packages".
I recommend a a three step upgrade.
1) upgrade acs-kernel, acs-authentication, restart
2) upgrade remaining core packages, restart
3) upgrade remaining optional packages, restart.
Heya Dave and the group,
I have copied the content of the compatibility matrix so I can play with it, and here's the copy. I put a green spot for openacs-5.7 and postgres-8.3 onward, with a link to this thread; I'm asking for success reports related to 5.6 and 5.7 on all relevent components. If you've tested with tcl-8.5.x, please say so.
What are the compatibilities with the other components?
- Anyone paying attention to oracle anymore?
- I understand aolserver is now at 4.5.2; what's the minimum aolserver version compatible with 5.7? Maybe 4.0.10?
- I also assume tcl-8.4 is the minimum usable; has anyone tested with tcl-8.5?
I think the emphasis continues to be on keeping openacs releases compatible with the current OS releases for each of platforms.
FreeBSD is a main, stable release platform, because of ongoing, proactive work provided by the wu-wien.ac.at group and others.
I've been unsuccessful at installing openacs on ubuntu under limited time constraints; Apparently, ubuntu is using the releases from Debian, which are stable on Debian, but don't necessarily work well on ubuntu, due to release timing, changing dependencies etc.
The main OpenACS issue seems to be upgrading between pg8.3 and pg8.4, namely dealing with changes in tsearch and perhaps ltree. At least tsearch has been incorporated into the main distribution, changing references and requiring some openacs code changes. I believe there's a thread or two about that. I haven't made the jump to pg8.4 locally, so haven't collected the references for that yet.
Tcl: TIP #143 approved to make Tcl 8.5 a platform requirement for OpenACS 5.6+. Tcl 8.4.* is not maintained anymore (see the tip for a more detailed rationale). Therefore would should put a "no" into OpenACS-5.7/tcl-8.4, although it might probably continue to work for a while.
Concerning versions of PostgreSQL: OpenACS 5.8 (currently, the head version) works with pg 9.1 as it is shipped (with the postgres configuration out of the box). I implemented the related changes in July last year. The summary of changes below is from my mailing to oct from this time (just updated version numbers and dropped unnecessary stuff), but might help maintaining the compatibility matrix...
PostgresSQL 9.1 was released in Sept 2011 and has - among a long list of other changes - one noticeable change for OpenACS: the default handling of standard conforming strings has changed  (instead of the non.standard backslash escaping). This change effects nspostgres as well as many of the .sql files in oacs-core, which are written in the hard-to-read single-quote style with backslash escapes, and not in the recommended $$-quoting style of PL/pgSQL (see e.g. ). I think, we should take the opportunity, update the quoting style and bring the sql files closer to the current state of the art in pg. Sooner or later pg 9.1 will be standard in the Linux distros.
Some deficits of the current .sql-files are:
- single quotes around the functions (quoting hell1)
- using backslash escapes (quoting hell2)
- using function arg aliases instead of writing the argument names in the function definition line
- using the home-made define_function_args instead of function argument defaults (many definitions for function_args are missing, many defined ones are incomplete - therefore the xo::db-procs relied on the comments in the function argument's alias definitions).
- with the defaults for function arguments in use, one could query defaults/names/types directly from the pg catalog tables.
Since i did not want to express just wishes, I invested some more time on the feasibility of such changes, and i think, performing all these changes in one swap is too ambitious for various reasons (more details below), so i would suggest the following two steps:
- upgrade to the $$ notation (recommended since pg8.0, jan 2005).
- get rid of backslash usages in function definitions
- drop aliases in favor of named function arguments (recommended since pg8.0)
- fix wrong function_args, add missing function_args, align default semantics with the defaults in pg (providing "null" as default means the argument is optional).
The second step is more ambitious, since it requires sites to use at least pg8.4 and requires argument renaming (or keeping function-args or similar for name mapping, which is as well a hack).
- use function argument defaults of PL/pgSQL (supported since pg 8.4, feb 2008).
- the function_args hack would not be needed anymore,
- redundant definitions must be removed (if there is a function with all defaults specified, functions with the same types but less arguments are not allowed)
- names of the function arguments have to be updated to match the ones provided currently via function_args(). The names in the function argument aliases are named like e.g. "v_item_id", while the names in the function_args are like "item_id". Without renaming, db_exec and maybe other functions would require different variable names. Changing this does not appear feasible.
All the changes of Step 1 for OpenACS core are committed to CVS since July 2011. Fresh installations run the regression test (aa-test) under pg 9.1. I have tested the same version as well successfully with pg 8.4.
The change is huge.
Another mostly cosmetic change that would be nice to adopt is the availability of anonymous code blocks, (i.e., 'DO ...' rather than creating a function and calling it immediately), but that's only since pg9.0 which is at least for now too much dropping backward compatibility.
They could be used as a namespacing mechanism; for example the calendar package might use a 'calendar' schema with a 'new' function within that schema (similar to oracle packages), and the function would be 'calendar.new' rather than 'calendar__new'.
Would there be any tangible benefit from doing so? Hard to say, it's mostly just a naming convention. But there also seems to be no downside, which is why wondering why they aren't used. (changing everything to using '.' instead of '__' is obviously a pretty big disruption of course)
The reason, why SQL schemas are not used in OpenACS is for historical reasons: when the postgres port was done, schemas were not supported by postgres. When using schemata, it would certainly make sense to move not only stored procedures into the schema space, but as well the tables defined by the packages, every package could be contained in a tcl namespace and sql schema ... and then, one should do the same for oracle as well. As you mentioned the benefit is not huge; from my experience is more likely that you get hate-mails, when you break something, than love-mails, when the components work as before.
I see a move to SQL schemas of less priority than Step-2 above (currently, debugging the function with the varying argument lists is painful, querying the default values from the postgres meta data does not work, we have hacks in OpenACS to work around this).