Forum OpenACS Development: Re: ]po[ V5.2 on OpenACS 5.10.1 Docker (Re: OpenACS 5.10.1 via Docker Stack)

Hi Frank,

sorry that i missed your original posting, I am quite busy with other projects these days.

timing issue

The docker-level healthcheck for the service should take care of this. When developing it, I tested this on multiple environments without problems.

The other points are NOT related with the container, but about upgrading PO.

pretty_plural

Without going deeper, there seems to be a PO data model issue, the metadata model seems incomplete. The function "create_attribute" is only called, when tuples in the OpenACS metadata model are missing.

In OpenACS, one sees:

oacs-head=# select attribute_id, attribute_name,pretty_name from  acs_attributes where attribute_name = 'object_id';
 attribute_id | attribute_name | pretty_name 
--------------+----------------+-------------
           74 | object_id      | Object ID
(1 row)

When the attribute is available in the metadata model, it does not try to create it. Nevertheless, you are right, one should not get errors, when the startup tries to repair a broken meta-data model.

invalid command name "::acs::dc"'.

This command is defined in acs-tcl/tcl/acs-db-00-procs.tcl When the file is sourced, the command will be available - unless some earlier error prevented loading

OID and tsearch

Have you seen: https://openacs.org/xowiki/upgrade-pg96-pg13

These instructions address OID dropping and excluding public.pgts* to avoid tsearch problems when upgrading from very old versions from before OpenACS 8.3 (2014).

Some more insights on the pretty_plural issue. When listening acs::dc call acs_attribute create_attribute one gets

 <instance of acs::db::nsdb-postgresql[i]> call acs_attribute create_attribute \
    [ -dbn dbn ] -object_type object_type  \
    -attribute_name attribute_name  -datatype datatype  \
    -pretty_name pretty_name  [ -pretty_plural pretty_plural ] \
    [ -table_name table_name ] [ -column_name column_name ] \
    [ -default_value default_value ] [ -min_n_values min_n_values ] \
    [ -max_n_values max_n_values ] [ -sort_order sort_order ] \
    [ -storage storage ] [ -static_p static_p ] \
    [ -create_column_p create_column_p ] \
    [ -database_type database_type ] [ -size size ] [ -null_p null_p ] \
    [ -references references ] [ -check_expr check_expr ] \
    [ -column_spec column_spec ]

You see, pretty_plural is optional. The argument list of all acs::dc call" functions is generated automatically from thefunction_argsdefinitions of your installation. I conclude, that my previous hypothesis of what might be different in PO, was probably not right, but i guess now that thefunction args` might be different.

Can it be that PO misses some of the upgrade scripts from OpenACS 5.7 or OpenACS 5.8?

acs-kernel/sql/postgresql/upgrade//upgrade-5.8.0d1-5.8.0d2.sql:select define_function_args('acs_attribute__create_attribute','object_type,attribute_name,datatype,pretty_name,pretty_plural;null,table_name;null,column_name;null,default_value;null,min_n_values;1,max_n_values;1,sort_order;null,storage;type_specific,static_p;f,create_column_p;f,database_type;null,size;null,null_p;t,references;null,check_expr;null,column_spec;null');
acs-kernel/sql/postgresql/upgrade//upgrade-5.7.0d3-5.7.0d4.sql:select define_function_args('acs_attribute__create_attribute','object_type,attribute_name,datatype,pretty_name,pretty_plural;null,table_name;null,column_name;null,default_value;null,min_n_values;1,max_n_values;1,sort_order;null,storage;type_specific,static_p;f');

All the best
-g