Forum OpenACS Q&A: Best way to modify a service contract input / output?

There's an small bug in acs-authentication that implies the change of the input values declared on a given SC, the thing is to try to find the best (less painful) way to handle that change, the only path now is to drop the SC implementations and the SC itself, and then re-create all of them, but this steps might be no so cleaner for this specific case.

So, since the one that deals with the inputs is acs_sc_msg_type__new, we might create a simple:
acs_sc_msg_type__new_add ...? (just for adding new inputs, the only thing that will be added to this proc is to start in the right element_pos, or maybe integrate it with the already existing function)
or acs_sc_msg_type__update, but will require to check more stuff...

There's something that I'm not seeing that might make the things go wrong?

suggestions ...?

Collapse
Posted by Don Baccus on
Well, it would be awfully nice to have a way to modify a service contract and not just in this way.  I'll be facing similar issues when writing upgrade scripts for the new-portal to portal migration but haven't looked into it yet.
doing something like this solved the problem (note that you need to know what are the actual msg_type_name's):

set sc_change [list {auth_authentication.Authenticate.InputType} {auth_password.ChangePassword.InputType} {auth_password.ResetPassword.InputType}]
    set element_msg_type_name integer

    foreach msg_type_name $sc_change {

    set element_pos [db_string get_pos { select max(element_pos) from acs_sc_msg_type_elements where msg_type_id = (select msg_type_id from acs_sc_msg_types where msg_type_name = :msg_type_name) }]
    incr element_pos

    acs_sc::msg_type::element::new \
        -msg_type_name $msg_type_name \
        -element_name authority_id \
        -element_msg_type_name $element_msg_type_name \
        -element_msg_type_isset_p f \
        -element_pos $element_pos

    }

Of course, a generic API for this will be better.