Forum OpenACS Development: How do you upgrade a service contract?

1: How do you upgrade a service contract?

Posted by Lars Pind on 06/12/03 10:04 AM

Hi all,

I'm making a slight change to notifications, allowing us to store which user caused the notification to happen, so we can send the email 'as' that user.

Now, the current notifications delivery method service contract doesn't include any argument that lets us pass that info on to the delivery method's Send proc. I'm going to have to add another argument to the service contract.

But what's the proper way to do that?

1) write a small SQL script to manually insert the new argument into the message type. That'll break other people's implementations of this service contract, if there are any (which I don't really think there are).

2) delete the old service contract and create a new one with a new name. That'll cause old implementations to go unbound. It won't cause any errors, they just won't work anymore.

3) Delete old service contract, create new with the same name. I think the situation is like above: Old implementations will go unbound, but won't error out. Presumable (what happens if you call an unbound service contract?)

/Lars

2: Re: How do you upgrade a service contract? (response to 1)

Posted by Jade Rubick on 06/12/03 07:34 PM

Couldn't you bump up the package version, and then make any new packages that use the new feature require the new version.

Hmm, I see what you're saying.

Perhaps we need an incompatible flag in the APM, which if set, means you can't upgrade a package without also upgrading another package at the same time.

Then any packages using the older notifications would have to be upgraded before notifications could be upgraded.

Would that work?

3: Re: How do you upgrade a service contract? (response to 1)

Posted by Neophytos Demetriou on 06/16/03 05:56 PM

Basic assumption behind a service contract is that the interface would not change once it is published. However, unless there are other implementations of the service contract (so people, speak up in that case) I would suggest that you go ahead and change the current service contract (better manage an interface rather than many). In case people wrote implementations based on the current contract, it would be better to fork that service contract with the appropriate changes into a new one (in which you would have the flexibility to add/remove more things).

Given this opportunity, as soon as I have some free time I intend to post about some changes/thoughts on the acs-service-contract package that I had in mind (OT: btw, if someone is interested to port my RSS package into oracle, pls email me, so that we can commit it to the repository. Currently, it's postgres-specific and the UI has to be rewritten with openacs templates but that's not too much work).