Hi Michael — nice, that is good news.
About the top_portlet error: this looks like a bug/ambiguity in apm_parameter_unregister. The generated SQL tries to match
where parameter_id = 'top_portlet'
so Postgres complains because parameter_id is an integer.
This is likely triggered by XoWiki’s upgrade step to 0.120, which includes:
set v 0.120
if {[apm_version_names_compare $from_version_name $v] == -1 &&
[apm_version_names_compare $to_version_name $v] > -1} {
ns_log notice "-- upgrading to $v"
delete_parameter top_portlet
}
Historically, an earlier upgrade (towards ~0.79, ages ago) renamed/copied the parameter from top_portlet to top_includelet. The later step (0.120 - 17 years ago) just tries to delete the obsolete name. Everything works fine even if this cleanup doesn’t happen; it’s housekeeping.
I’ve fixed the underlying apm_parameter_unregister issue in CVS HEAD and in oacs-5-10. So the practical fix is: update to a revision that includes this patch (acs-tcl/APM), then re-run the upgrade.
If you want to inspect your current DB state, you can check whether these parameters exist and what they contain:
select v.package_id, p.parameter_name, v.attr_value
from apm_parameters p
join apm_parameter_values v on (v.parameter_id = p.parameter_id)
where p.parameter_name = 'top_portlet';
and:
select v.package_id, p.parameter_name, v.attr_value
from apm_parameters p
join apm_parameter_values v on (v.parameter_id = p.parameter_id)
where p.parameter_name = 'top_includelet';
Regarding ordering: no worries there — OpenACS/APM computes the upgrade order from dependencies, so you don’t need to handle xotcl-core vs. xowiki sequencing manually.
all the best -g
