Database Context Support in Plugins

[pandinocoder]

There is nothing technically speaking that impedes plugins from using and maintaining their own contexts already, but ideally the server can help plugin authors set this up and track things.

What this does not do:

• Allow changes to the existing contexts
  • This is extremely discouraged for source modifications, and more or less not possible for plugins
• Generate migration scripts
  • Since they will be separate contexts, plugin authors will need to generate their own migration scripts the same way core contexts get generated, but against the plugin's project instead of the server

What this does do:

• Allow plugins to register their own DB context types during the bootstrapping phase (not instances, we're trying to start using EF the correct way)
• Run created migration scripts against each DB context
• Provide new DB context instances
• Provide similar/same diagnostic/logging information for custom contexts as is provided for built in contexts

What this might include:

• Metacontext for mapping between contexts
  • This may not end up being all that useful
• Inter-context data loading layer or utility leveraging metacontexts
• Type-Context exclusive association for data dependency mapping/loading

[pandinocoder]

This needs further input and discussion on implementation details.