SQL Server Broker：如何修改合同？

Question

How do I add a new message type to an existing contract?

CREATE CONTRACT and DROP CONTRACT commands exist, but no ALTER command.

Answer 1

ALTER CONTRACT is not amiss due to omission, is missing by design . This is exactly like asking to change COM interfaces: is not supported, because the interface is a contract . If one party changes the interface, it breaks the contract and will cause the other party to crash when calling the wrong v-table entry. Exactly the same reasoning was applied in Service Broker design: one party cannot change ( ALTER ) the contract and start sending some new messages the other party does not expect, it will cause it to crash (error in the message processing procedure). Contracts are immutable .

If you say 'but I can ALTER the other party too' then you are not considering real use cases, when the other party is remote and often under a different administrative control and not willing to change its contract(s). even when a change is possible, deploying a distributed change that requires many side to roll out new bits is just asking for (unnecessary!) downtime.

Changes in communication pattern must be deployed as new contracts. Services can implement multiple contracts, and adding a new contract to a service (via ALTER SERVICE ) is supported. Changes in distributed apps are rolled out by deploying new contract(s) while still supporting old one(s), then retiring old contract(s) (ie. overlap ).

Answer 2

From here :-

A poor workaround to this would be to version all changes as new contracts but that would require an additional service and queue and existing conversations would not be able to benefit from the new message type.

I highly recomend support for an alter contract command but also add support for SSDT to issue an alter command instead of drop/create.

I highly reconsideration of this request. Or at a minimum: Add a check and error message to be raised from SSDT whenever any conversation exists that uses that service and/contract before dropping in a similar way that SSDT checks for existing data in a table before dropping said table. This would at least help raise awareness of this side-effect and would have prevented deployment headaches.