Create logic to delete dynamically created tables upon module uninstall

[valadas]

This can only be done after this is done dnnsoftware/Dnn.Platform#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]."

[thabaum]

To add to @WillStrohl talking points is:

• A backup should always be a way to recover data lost.
• A way to "export" each structured content type and other things created by this module prior to deletion of the module with a way to import later would be nice. This would create a way you can move data between sites as well.

Little old maybe just seen the post.

[X3Technology]

A way to export/import both the data and the structure/visualizers are on the planned roadmap.

[thabaum]

Then if someone really wants to only have structure data imported, they just need to import that data structure into the module and simply not create a visualizer for it.

But what "If" someone wants to uninstall the "Structure" I think is the main concern with @valadas. Should this delete the data as well. Expected answer is yes.

Only if there was an option for not deleting data. Then it brings the question if this option is set what data structure information get removed or saved for module uninstall purposes leaving only the structured data desired?

Maybe I could see on the options for the StructuredContent there can be an option Module Uninstall Behavior: Never Delete Data to ensure this data is always preserved during an uninstall process. But if the module is ever installed again down the road how does it treat this data? Will it recognize it somehow as being a part of that module in the past?

[X3Technology]

It should behave just like it would if you uninstalled any DNN module. If you delete the Blog module, all the Blog data goes with it. Unless you somehow exported the data out before you deleted the module.

We will have a way to export the data into JSON (or XLS/CSV/XML). And a way to export/share ContentTypes.

[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.