Forum OpenACS Development: Re: acs-object-management issues

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.