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

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?

Thanks!
Frank

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.object_type,
 acs_objects.title as object_title,
 acs_objects.package_id as object_package_id,
 acs_objects.context_id,
 acs_objects.security_inherit_p,
 acs_objects.creation_user,
 acs_objects.creation_date,
 acs_objects.creation_ip,
 acs_objects.last_modified,
 acs_objects.modifying_user,
 acs_objects.modifying_ip,
 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

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!
Frank