Skip to content

Triggering migrations for first time #1223

@kirtangajjar

Description

@kirtangajjar

Background

Earlier in easyengine, all the tables were created from core. When the EE_DB class was initialized, we used to check if ee.sqlite file exists, if not we used to create all tables.

Now since we've moved package specific code to the respective packages, we also moved table creation logic to individual packages in form of migrations. So we now need to run migration after installing ee and after each upgrade.

The problem is in triggering migrations first time after installing ee.

The problem

Triggering migration first time is a problem since we don't know if ee is being run first time.

Unfeasible solutions already thought of

  • Trigger migrations after installation script
    • We cannot do that as if someone uses the phar directly, things will break
  • Trigger migrations when the EE_DB class is initialized(as was done before)
    • This too cannot be done as migrations now contain logic for both filesystem based migrations and database migrations. So if a command is executed which does not invoke EE_DB but expects the filesystem migrations to be ran, than that command would fail.
  • Trigger migration if ee.sqlite file is not found
    • If migrations have been ran previously then ee.sqlite file would be present. There's a case where if the migration was running previously but somehow the process got terminated while executing, then ee.sqlite file would be present but the migrations might not have been ran completely

Possible solutions

So the only solution it seems is to somehow check if migrations are run or not on each ee invoke.
However it can be expensive operation to do as we check migrations from each package and see if it's present in database or not.

  • One simple solution would be to use a filesystem cache(EE already has this) to store if migrations have been ran. So on each ee run, we'll check in this file if there's a key value pair that indicates ee's migration has been ran. If it has, it'll skip triggering migrations else it will trigger it.
  • Instead of keeping on filesystem cache, we can create a ee_options table and track if migration has been ran in there.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions