Forum OpenACS Development: Re: OpenACS 5.9.0: journal_article and Edit This Page

Posted by Frank Bergmann on

We finally made it. There was a misunderstanding due to the journal_* prefix:

- journal_entry is defined in acs-kernel while
- journal_issue and journal_article are defined by ETP

So we'll now include a hand-written SQL cleanup-script for ETP.
This script also removes an entry of "journal_entry" (the acs-kernel object type) in content_types. No idea how this ever has gotten there, but journal_entry definitely doesn't belong there. Here is the cleanup script:

drop rule if exists journal_article_r on journal_articlei;
drop function if exists journal_article_f(journal_articlei);
select content_type__drop_type('journal_article', 'f', 'f');
drop view if exists journal_articlei;
drop view if exists journal_articlex;

drop rule if exists journal_issue_r on journal_issuei;
drop function if exists journal_issue_f(journal_issuei);
select content_type__drop_type('journal_issue', 'f', 'f');
drop view if exists journal_issuei;
drop view if exists journal_issuex;

-- Somebody also made journal_entry a content-repository data type...
select content_type__drop_type('journal_entry', 'f', 'f');

So this specific problem seems to be fixed now.

However, we've not got similar problems re-generating the content-repository views for file_storage_object. However, this time we can't just cleanup stuff.

=> Can somebody tell me how to generate this file_storage_objectx table or view?


psql:file-storage-create.sql:67: ERROR:  relation "file_storage_objectx" does not exist
LINE 16: ...ctx.* from acs_objects, cr_revisions cr, cr_text, file_stora...
QUERY: create view file_storage_objectxi as select acs_objects.object_id,
acs_objects.title as object_title,
acs_objects.package_id as object_package_id,
cr.revision_id, cr.title, cr.item_id,
content_revision__get_content(cr.revision_id) as data,
cr_text.text_data as text,
cr.description, cr.publish_date, cr.mime_type, cr.nls_language, file_storage_objectx.* from acs_objects, cr_revisions cr, cr_text, file_storage_objectx where
acs_objects.object_id = cr.revision_id and acs_objects.object_id = file_storage_objectx.object_id

Posted by Gustaf Neumann on
Hi Frank,

where is the query above coming from? The view for the file_storage_object is supposed to be created via select content_type__refresh_view('file_storage_object'), which should create the two views

  • file_storage_object_ti, and
  • file_storage_object_tx,
but no file_storage_objectxi (what you are trying to create).

The last changes in this area were done more than six years ago [1] (in OpenACS 5.6). Can it be that you have missed some update scripts on file storage around that time? For your reference, on OpenACS 5.6 or newer, the type definition should look like

oacs-5-9=# select object_type, supertype, table_name, id_column, package_name  from acs_object_types where object_type like 'file%';
     object_type     |    supertype     |      table_name       |       id_column        |    package_name     
 file_storage_object | content_revision | file_storage_object_t | file_storage_object_id | file_storage_object
(1 row)


Posted by Frank Bergmann on

I have no idea how the file-storage installation in ]po[ had the view "file_storage_objectx" as "table_name". It's perfectly possible that we have missed some upgrade scripts. However, the package actually works.

Anyway, this seems to be the last data-type with content-repository upgrade issues. We will now uninstall file-storage completely and reinstall. This process is a bit ugly, because file-storage is used by the packages xowiki and attachments, but I hope it will work out...

Thanks for the help!

Posted by Gustaf Neumann on
If someone else sees the problem above when upgrading old sites via acs-kernel/upgrade-5.9.0d4-5.9.0d5.sql, please run first the following SQL command in psql:
update acs_object_types set table_name = NULL, id_column = NULL where object_type = 'file_storage_object';