Create logic to delete dynamically created tables upon module uninstall

[valadas]

This can only be done after this is done https://github.com/dnnsoftware/Dnn.Platform/issues/2160

But the idea is that if someone would uninstall the module, it should not leave data behind and most of the data tables where dynamically created so would need to be done from code.

[X3Technology]

It possible that the user might not want to delete all the dynamically created tables. They may have started with the StructuredContent solution and then decided that they want to build a custom module on top of the tables instead but not lose all their data.

[mitchelsellers]

I would concur with @mathisjay on this one. Given that the "other tables" are all things that would be 100% deletion of user data I almost think it needs to be a release notes or otherwise discussion that they clean those tables up. (Not ideal I know, but we also know how many times people accidentally uninstall modules too)

[WillStrohl]

If this is a standalone module (never getting added to the DNN core), that's a different scope and conversation. If we continue to entertain adding this to the core, there are a few things to consider:

1. Best practices dictate that the database schema is deleted when an extension that added it is deleted.
2. Existing DNN administrators are used to and expect data to be deleted when a module is uninstalled (unless they personally built it to do otherwise).
3. Every organization has a different data-retention policy and it can vary in many jurisdictions. We can't reasonably try to be compliant with any of them.
4. Core modules typically are not uninstalled. So, the data will remain regardless.

If we move toward this not going into the core, then we can do whatever we want, but there's no UI to let people know that data will still be there and essentially be orphaned. I personally know that I can expect some uncomfortable situations where I have to explain why this module works differently than others. Typically, that conversation would be more like this, "If you want to retain the data, we can just run a script to move it to [insert a corporate location here]."

[X3Technology]

I could see the arguments for both sides. However, I am looking at this at the entry point for a headless CMS solution as well.

The Visualizer module is simply one potential consumer of the dynamic data tables the StructuredContent solution builds.

The bulk of the functionality (thus far) is in the admin interface for creating tables on the fly and presenting a nice interface for a content editor to manage the content. Furthermore, I envision having built-in "system" ContentTypes like Images, Documents, Videos, that would manage those types of web content. We could even build "picker" like controls (web components!) that could be embedded in other third party modules but the management of the those content items would be handled by this system.

The Visualizer page module is just the "last mile" so to speak. In fact, I could easily see people using this system to create and manage the data and then using a completely different solution to consume/display the data. In fact, these could really be two separate projects, but I know we need to deliver some type of 'last mile' solution to be useful for now.

So, it's a little bit of a different paradigm to the traditional model where the data is so tightly coupled to the presentation of the data that if you delete the module extension, you don't want the data anymore.