Forum OpenACS Development: acs-object-management issues

Collapse
Posted by Jeff Davis on
Installing acs-object-management fails if categories or xowiki are installed already...

Categories creates 2 rels in categories-relation.sql which references tables meta_categories and user_meta_categories which it does not create. AOM install fails with the following

QUERY:  create or replace view meta_category_rel_v as select acs_objects.object_id as meta_category_rel_v_id,acs_objects.tree_sortkey,acs_objects.title as title,acs_objects.modifying_ip as modifying_ip,acs_objects.creation_ip as creation_ip,acs_objects.object_type as object_type,acs_objects.object_id as object_id,acs_objects.package_id as package_id,acs_objects.context_id as context_id,acs_objects.creation_user as creation_user,acs_objects.modifying_user as modifying_user,to_char(acs_objects.last_modified, 'YYYY-MM-DD') as last_modified,to_char(acs_objects.creation_date, 'YYYY-MM-DD') as creation_date from meta_categories, acs_rels, acs_objects where  acs_objects.object_id = meta_categories.meta_category_id and  acs_objects.object_id = acs_rels.rel_id
CONTEXT:  PL/pgSQL function "acs_view__create_sql_view" line 78 at EXECUTE statement
SQL statement "SELECT acs_view__create_sql_view(p_type || '_v')"
PL/pgSQL function "acs_object_type__refresh_view" line 82 at PERFORM
SQL statement "SELECT acs_object_type__refresh_view(v_type_rec.object_type)"
PL/pgSQL function "acs_object_type__refresh_view" line 94 at PERFORM
SQL statement "SELECT acs_object_type__refresh_view(v_type_rec.object_type)"
PL/pgSQL function "acs_object_type__refresh_view" line 94 at PERFORM

psql:acs-kernel-changes-create.sql:936: ERROR:  relation "meta_categories" does not exist
LINE 1: ...reation_date, 'YYYY-MM-DD') as creation_date from meta_categ...

Setting the tablename and id column to null in acs_object_types fixes that, but then the xowiki object types try to create views like ::xowiki::Package_v since it assumes object_type is suitable as part of a view name.

psql:acs-kernel-changes-create.sql:936: ERROR:  syntax error at or near "::"
LINE 1: create or replace view ::xowiki::Package_v as select acs_obj...
                               ^
QUERY:  create or replace view ::xowiki::Package_v as select acs_objects.object_id as ::xowiki::Package_v_id,acs_objects.tree_sortkey....

If I install AOM first, then install categories/xowiki etc. xowiki installs without errors but then does not work. There seems to be some change acs-object-manager makes that breaks some assumptions in xowiki. The object in xowiki/www/index.vuh is then missing all the methods from the xowiki package (in particular the invoke method).

Collapse
Posted by Michael Steigman on
Hi Jeff,

I dealt with some of these issues a little while back when exercising some of the new functionality. This particular issue was never brought up with the OCT. If you haven't resolved it locally yet, a quick fix is to alter line 405 of acs-kernel-changes.sql (inside acs_object_type__refresh_view) to look like:

v_view := replace(p_type, ''::'', ''__'') || ''_v'';

and then recreate the function. That'll work around the issue with xowiki. We did not come to any consensus about a more permanent solution. The code was still so experimental, we were happy to have that workaround (and not so urgently concerned with xowiki ramifications - afaik, there are parallel but unrelated efforts in the xowiki world) so we punted.

Other data model changes (outside the category changes you mentioned) I had to make involved a lot of dotlrn crud. I'll just put them here in case others are interested in trying stuff out.

-- fix object type metadata for dotlrn application_group subtypes
update acs_object_types set id_column = 'community_id', table_name = 'dotlrn_communities' where object_type = 'dotlrn_community';
update acs_object_types set id_column = 'class_instance_id', table_name = 'dotlrn_class_instances' where object_type = 'dotlrn_class_instance';
update acs_object_types set id_column = 'club_id', table_name = 'dotlrn_clubs' where object_type = 'dotlrn_club';

-- and some others
update acs_object_types set id_column = null, table_name = null where object_type = 'dotlrn_guest_rel';
update acs_object_types set id_column = null, table_name = null where object_type = 'dotlrn_non_guest_rel';
update acs_object_types set id_column = null, table_name = null where object_type = 'meta_category_rel';
update acs_object_types set id_column = null, table_name = null where object_type = 'user_meta_category_rel';
update acs_object_types set id_column = null, table_name = null where object_type = 'as_inter_item_check';

-- remove bogus metadata which was causing new attribute view refreshes to fail
select acs_attribute__drop_attribute('dotlrn_member_rel','portal_id');
select acs_attribute__drop_attribute('portal_datasource','CONTENT');
select acs_attribute__drop_attribute('portal_layout','TYPE');
select acs_attribute__drop_attribute('portal_element_theme','TYPE');

Collapse
Posted by Jeff Davis on
There is actually a smoke test in automated testing that catches all this...

Test case datamodel__acs_object_type_check

There is one for the attributes as well.

Collapse
Posted by Dave Bauer on
It seems like you could just remove all non A-Z_ characters from the name and replace them with _ to be totally safe and catch any other potential problems.
Collapse
Posted by Jeff Davis on
I committed a change to map : to _ so it does not bomb. As for making it a valid db name -- yeah that seems reasonable too.

Here is what the PG manual says about identifiers:

SQL identifiers and key words must begin with a letter (a-z, but also letters with diacritical marks and non-Latin letters) or an underscore (_). Subsequent characters in an identifier or key word can be letters, underscores, digits (0-9), or dollar signs ($). Note that dollar signs are not allowed in identifiers according to the letter of the SQL standard, so their use might render applications less portable. The SQL standard will not define a key word that contains digits or starts or ends with an underscore, so identifiers of this form are safe against possible conflict with future extensions of the standard.