Migration management

[BenediktMKuehne]

With Django projects the general best practice is (according to the offical-docs) to add handle migration-files as part of the code-base.

But since there eventually will be multiple instances deployed, now would be a good time to decide on migration management.

Quick explanation:
EMBArk uses a mySQL database, which is conveniently managed through Djangos migration-files.
Which apply all changes made to fields, tables etc. to the database.
If for example a new field like firmware_name is added to the firmware-table (model), django creates a new migration-file for these changes.

Now there are 2 options once we (hopefully soon) consider EMBArk officially in release:

1. Have all migration-files (changes to the db-schema) inside the source-code:
   👍 minimal to no manual intervention between updates
   👎 possibly disproportional growth of code-base
   👎 new installations would take more-and-more time
   ➡️ EMBArk does management centralized for the user and can better help if something goes wrong

2. Let the user (automatically or manually) create its own migrations (Keep it like it is):
   👍 every instance would only generate the changes (migrations) it itself needs - faster and less code
   👍 more control over individual instances
   👎 divergent code-base - semi uniqueness between db and migrations
   ➡️ EMBArk runs in forks (or other version-control)* and it gets harder to help if something goes wrong**

---

• since you would have to version-control your individual applied migrations
  ** this might of course cause a plethora of questions and issues that are hard to reproduce

[BenediktMKuehne]

Migrations get created, applied and synced on server-startup now.
DB consistency part of the end-users responsibility.
I can only recommend to make complete backups!