Forum OpenACS Development: Re: upgrade-5.9.1d15-5.9.1d16.sql breaks acs_rel_type__create_type
is it possible that ]po[ ships a custom 15 arguments version of acs_rel_type__create_type? This seems to me the simplest explanation for your issue.
Please double check the definitions of this function in your code or in the database and make sure this was not extended/customized downstream, we can give more suggestions from there.
Thanks for the quick response and your time!
15 arguments version
That is correct. But it was not customized.
We use exactly the same acs_rel_type__create_type since ACS 3.4 (before OpenACS!). Here is an example:
select acs_rel_type__create_type (
'im_agile_task_rel', -- relationship (object) name
'Agile Task Rel', -- pretty name
'Agile Task Rel', -- pretty plural
'relationship', -- supertype
'im_agile_task_rels', -- table_name
'rel_id', -- id_column
'intranet-agile', -- package_name
'im_project', -- object_type_one
'member', -- role_one
0, -- min_n_rels_one
null, -- max_n_rels_one
'acs_object', -- object_type_two
'member', -- role_two
0, -- min_n_rels_two
null -- max_n_rels_two
You must have had a very good reason to break this compatibility? Maybe you can explain the reasoning behind? And was it really necessary to delete the previous version of the call? Why not create a different signature of the procedure to maintain compatibilitiy?
This is the 3rd or 4th incompatible change that I've seen in the last years. I'm not sure about the reasoning process behind this. We actually did not upgrade to OpenACS 5.10 because there were additional errors due to incompatibilities.
My point is: Please check with "us users" of OpenACS before performing incompatible changes. I know that Quest has similar issues, and I understand there are several other projects depending on a stable API.
I can offer you a "test lab in a box" (or better "in a VM") to allow you to quickly check if a new OpenACS version is compatible or not.