feat: migrations

[janbritz]

Basiert auf questionpy-org/questionpy-server#195

Migrations können folgendermaßen erstellt werden:

from questionpy import Migration, SideMigration


class V1(Migration):
    def upgrade(self):
        self.options["question"] = self.options["old_question"]
        del self.options["old_question"]

        self.state["state"] = "x"


class X(SideMigration, for_namespace="qpy", for_short_name="test", for_state_version=7):
    def sidegrade(self):
        self.options["question"] = self.options["old_question"]
        del self.options["old_question"]

Diese müssen in einem Python-Package mit dem Namen migrations definiert werden. Migrations werden nach dem Namen der Python-Datei, in welcher sie definiert wurden, sortiert. Es können auch mehrere Migrations in einer Datei leben, da zusätzlich auch nach dem Klassen-Name (genauer __qualname__) sortiert wird.

Beim Paketieren wird die state_version basierend auf der Anzahl der Migrations berechnet.

[MartinGauk]

Welchen Vorteil hat es, die einzelnen Migrations in Klassen zu stecken, die nur aus einer Methode bestehen?

[MartinGauk]

Hier wäre es besser statt nach der Anzahl nach dem höchsten/max Integer zu sehen. Falls man doch alte Migrations mal löscht, sollte das nichts durcheinander bringen.

[janbritz]

Was genau meinst du mit "höchsten/max Integer"? Ich hatte das damals im Meeting angesprochen, dass wir es erlauben sollten, Migrations zu löschen (Digital Waste / Übersichtlichkeit) - wir sind dann aber zum Schluss gekommen, dass wir das nicht wollen. Mit der jetztigen Implementierung könnten auch alle alten Migrations in einer Datei "versteckt" werden.

[MartinGauk]

Hier muss es dem Paket möglich sein, eigene Fehlermeldungen zurückzugeben.

[janbritz]

Das ist möglich wenn die Exception e vom Typ MigrationNotPossible ist (siehe).

Mir fällt gerade auf das hier SpecificMigrationError besser als SpecificMigrationFailedError passt.