-
Notifications
You must be signed in to change notification settings - Fork 432
Description
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_DBclass 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_DBbut expects the filesystem migrations to be ran, than that command would fail.
- 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
- Trigger migration if
ee.sqlitefile is not found- If migrations have been ran previously then
ee.sqlitefile would be present. There's a case where if the migration was running previously but somehow the process got terminated while executing, thenee.sqlitefile would be present but the migrations might not have been ran completely
- If migrations have been ran previously then
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_optionstable and track if migration has been ran in there.