Inputqueue and destinationaddresses should be able to contain multiple '.' without enforcing to use brackets

[jr01]

Currently the assumption is that if an inputqueue or destinationaddress contains a single '.' then it's prefixed with a SQL schema name, like "dbo.tablename". When there are 2 or more '.' then the assumption/suggestion/workaround/exception in the code is to enforce that all names are enclosed in brackets, like so "[some.nice.endpoint]". This workaround implies that when changing transports all existing client code needs to be changed, or have if(transport==sql)'s all over the place if multiple transports are used (unit testing, integration testing, production).

My suggestion is that the SQLserver transport (and it should probably apply to all transports...) is to allow any character in the provided inputqueue/destinationaddress/topic's and internally in the transport/subscription just format/map to a safe name if really needed. Next to this there can be configuration options to give flexibility where it's needed, e.g. for backwards compatibility and providing schema names.

So practically for the SQLserver transport I'm thinking about:

• Add a "UseLegacyNaming()" configuration option that internally uses a LegacyTableNameFormatter which has the current code in TableName.Parse/TableNameFromParts.
• Add a DefaultNameFormatter that just prefixes with "dbo.", Note that it's valid to have brackets in a SQL tablename.
• Provide a defaultSchema parameter to the DefaultNameFormatter to use instead of "dbo".

[mookid8000]

Hmm, my immediate reaction to this is 😐 then 😒 then some more 😐 then 😞

The naming scheme [schema].[table] was enabled to allow for using a schema other than dbo, but as you correctly noted, this very SQL Server-specific way of formulating queue names conflicts with almost any other transport – in fact, I think only the in-mem transport will allow these weird names.

If I understand you correctly, one of the solutions you propose, is to add the ability to default to a specific schema, and then treat queue names as plain table names.

In my head, it would look like this:

Configure.With(...)
    .Transport(t => t.UseSqlServer(..., "queue with spaces").WithSchema("rebus"))
    .Routing(r => r.TypeBased().Map<string>("some-queue"))
    .(...)
    .Start();

which would start an endpoint with the table [rebus].[queue with spaces] as its "input queue".

All messaging would then be using the rebus schema in this case, meaning that string messages would be sent to the table [rebus].[some-queue].

I feel this would be a pretty elegant solution, but it doesn't immediately support cross-schema messaging, though. Actually, I become quite tired, if I think of trying to support communicating between schemas, so maybe that should simply not be possible.

How does that sound?

[jr01]

YES, that should work 👍

[mookid8000]

I've added a new transport implementation ("new SQL Server transport"), which is available in Rebus.SqlServer 6.0.0-a2

If someone would try it and see if it works, that would be absolutely awesome 😁

[mookid8000]

Looks like it's working quite ok 🙂