Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Migrations #5155

Closed
nickvergessen opened this issue May 29, 2017 · 4 comments · Fixed by #5231
Closed

Migrations #5155

nickvergessen opened this issue May 29, 2017 · 4 comments · Fixed by #5231

Comments

@nickvergessen
Copy link
Member

Doctrine vs. ownCloud

I looked into Doctrine and ownCloud Migrations today, to see what would fit better with our needs. I saw that the difference is quite minimal:

  • Doctrine comes with dependencies for better symfony support (yml instead of a class etc) and to trigger zend-events (a forth event system in nc?)
  • ownCloud migrations have no "revert schema change" thing, but when you dropped a table/column you can't revert it back to get the data magically and I can see this point from DeepD

The code they come with is also rather minimal, since most of the PRs are the actual migrations.

I would now propose to go with ownCloud migration, only with two little changes:

Change 1 - Single type only

They have 3 migration types: schema, sql and simple: https://github.com/owncloud/core/pull/27041/files#diff-333567435f8bef9975c29c5e73ab7dd0R372

I would merge them all into one kind with:

  • preSchemaChange
  • schemaChange
  • postSchemaChange

Any of those can be empty. But it allows you e.g. to store data inmemory instead of temp dir, change your db schema and then restore the data again, like we already did it in https://github.com/nextcloud/server/blob/master/apps/twofactor_backupcodes/lib/Migration/CopyEntriesFromOldTable.php

If you dont change the schema, you just leave it unchanged and only change your data in pre/post.

Change 2 - Location

They have the migration files in appinfo/Migrations/ and load them via require_once. I would chose lib/Migration so we have normal autoloading.

cc @LukasReschke @rullzer

@ChristophWurst
Copy link
Member

I would chose lib/Migration so we have normal autoloading.

seconded 👍

@LukasReschke
Copy link
Member

Change 1 - Single type only

👍

Change 2 - Location

👍

@rullzer
Copy link
Member

rullzer commented Jun 1, 2017

I like the approach. Sounds clean!

🚀 👍

@nickvergessen
Copy link
Member Author

Found a little issue.
Currently migrations are "dated": 'Version' . date('YmdHis')

However when you have multiple major branches, or introduce a migration in an older version, it will skip all "older" migrations from the newer major branch are not executed anymore. So I propose to add a version in between which is given by the developer: 'VersionXYDate' . date('YmdHis')

This allows us to to correctly sort them. The thing is the engine only can sort by name, and doesn't sort by branch or whatever

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants