Support an Alternate Database Connection

[jeremy-farrance]

Like the old Reports Dnn module and others over the years, one addition I would like to suggest early in development and planning, is whether to use the default Dnn connection or instead, a different named connection (defined in web.config). I think the option to house all this data in a separate db will appeal to a lot of people for some use-cases.

I think it would be worth discussing or fleshing out the defaults, assumptions, and fallbacks. Its likely all that is needed is a global/default to fallback to always when a Named Connection is not specified. But I can also imagine use cases where the connection to use might be at the Dnn/Instance, Site/Portal, Module, or Tab/Module level. Use cases? Or maybe there is already a well defined pattern that covers this?

What about the granularity of each Entity/Table being able to have its own Connection? A bridge too far?

All that having been said, my suggestion is keep it simple to being with. One global setting for a Connection Name, otherwise use Dnn. All data created and Managed by StructuredContent goes in that one place. Then the only advanced thing to deal with is: how do they move their stuff from the Dnn db to the named connection later, after they've got stuff already in place and working?

Just an opinion... note that since Connection Strings are inherently an advanced option - due to the number of disciplines involved in getting them working, setup correctly, and securely - so I do not think StructuredContent should attempt to store or handle any of the setup logic beyond simply knowing the Connection Name. I don't think its a good idea for learn-as-you-go folks to attempt database creation/permissions, web.config editing, etc. "If you cannot plug a Connection Name in to StructuredContent that already works, don't try." :)

So, all that having been said. This should either get done soon or immediately get put on the Roadmap for v2 or v3. Or declined completely. Cheers!!

[mitchelsellers]

This is a unique concept, however, I do question if we should include such a feature given the complexity of management and risks associated with external databases?

[WillStrohl]

I agree with Mitch, but let's see what the community thinks. :)