Add single message table database schema again for easier upgrades

[oliverhanappi]

We are still using Rebus 4 and its single message table database schema as transport accross a decent amount of systems. Migrating to the "new" table per queue database schema introduced in Rebus 5 would currently require to update and deploy all systems at once.

It would be nice if there would be an option to enable the old single message table strategy. We would then be able to expose this option as feature flag which is far more easy to toggle accross multiple systems than rolling them out all in parallel.

@mookid8000 I would be happy to contribute the change but want to check first if the change would be accepted. If not we are probably going to fork Rebus.SqlServer and make the change anyways.

[mookid8000]

While it would of course be super-neat to have the ability to support the old mode of operation, I would fear that carrying both implementations forward would be too tedious to maintain.

If you could successfully fork the repo and add your own implementation to it, and it would not increase the complexity too much, then I would definitely consider merging it. But I am hesitant to encourage you to go down this route, because I would be afraid that you would end up doing a lot of extra work to accomodate both modes, with the possibility that I would say "too complicated!", and then your extra work would have been to no avail.

If I were you, I would just fork the v4 repo, bring its dependencies up-to-date, and then publish it for internal use.

What are your thoughts?

[oliverhanappi]

I want to support both database schemas side by side in order to be able to toggle them via feature flag. Otherwise it would be too much hassle to align the release schedules and deployments of all involved systems.

We are going to make the changes. If we think that the maintenance overhead is not too much we are going to create a PR and you can decide afterwards.

[mookid8000]

Ok, great plan 🙂