Backport support for schema name in the endpoint address

[mauroservienti]

The actual relationship between ServiceControl and the SQL Transport might be broken if users need to use multi-schema, multi-database or multi-instance features.

The broken relationship is a configuration design bug introduced in the SQL Transport, in moving forward with vNext of the transport we made the following changes:

• We decided to drop multi-instance support as it is now and we are investigating options to move forward
• We introduced multi-schema support using the endpoint address to be compliant with ServiceControl
• We have a plan to introduce multi-catalog support still using the endpoint address to be compliant with ServiceControl
• We are investigating options to provide multi-instance (or similar) support

given the fact that the actual production version of the transport has a design bug preventing it work correctly with ServiceControl @mikeminutillo @johnsimons @SzymonPobiega and I had a discussion on how to move forward and have decided that the following could be a nice to have:

• Update the actual production version to obsolete multi-instance support as it is now (do we need to release a major version to do this?)
• Backport multi-schema support in the endpoint address to the actual production version to enable ServiceControl support to customers using multi-schema
• Once v6 is released and multi-catalog is released backport multi-catalog support in the endpoint address to the actual production version to enable ServiceControl support to customers using multi-catalog
• Evaluate further options to enable true multi-instance support

@Particular/servicecontrol-maintainers @Particular/transport-maintainers please chime in

-- original description --

In order to support actual version of ServiceControl and reduce the pain for customers using multi-schema we should backport support for schema name in the endpoint address to SqlTransport V2

Inception: https://github.com/Particular/CustomerSuccess/issues/166

[SimonCropp]

-1

This is a feature and we should avoid backporting

[mauroservienti]

And this is preventing customers to use ServiceControl, that's why we proposed as we did for the previous version already to backport a fix that we introduced in a new version of the transport. I don't really see this as a feature we already support multi-schema in the actual version, the is implemented is the issue.

[mauroservienti]

@Particular/servicecontrol-maintainers @Particular/transport-maintainers please chime in

[johnsimons]

Update the actual production version to obsolete multi-instance support as it is now (do we need to release a major version to do this?)

Yes we do need to up the major version, since we are taking away existing functionality.

Once v6 is released and multi-catalog is released backport multi-catalog support in the endpoint address to the actual production version to enable ServiceControl support to customers using multi-catalog

Just to clarify, I would rephrase this as, add support for multi-catalog to existing production version, I do think this is probably something we want to do before the v6 compatible version goes out. I would package this and the removal of multi-instance together.

[johnsimons]

@mauroservienti let me know if you need help with pushing this to be higher priority then the current v6 work

[mauroservienti]

Had a quick recap call with @tmasternak and we agree that this should be possible. @tmasternak next step is to validate our assumptions looking at current implementation in V2 and report back here.

[tmasternak]

I've sync with @SzymonPobiega I looks that potential problems could be result of the fact that we explicitly ignore machine part (part after @) of the transport address in V2. That being said I think that we will see what are our options when we start fixing this.

[SzymonPobiega]

The problem with ServiceControl has been fixed via the Transport Adapter. Closing. @mauroservienti feel free to reopen if you disagree.