Migrate task in 1.2 release is not bumping database version during upgrades
|Assignee:||David Juhasz||% Done:|
|Target version:||Release 1.3|
|Google Code Legacy ID:||atom-2220||Tested version:|
To reproduce this error:
1) Upgrade a YAML file from 1.1 to 1.2 (use 1.2 tarball)
2) $ grep -A 5 -B 1 "name: version" migrated_data_20120112211615.yml
version field should be bumped to 75 (db version in 1.2) but 62 (db version in 1.1) is still there
- THE FIX SHOULD ALSO CONSIDER USERS WHO ALREADY UPGRADED TO 1.2 BUT THEIR DB VERSION IS STILL "62"
[g] Legacy categories: Migration task
#2 Updated by Jesús García Crespo over 8 years ago
20:29 < djjuhasz> Sevein: re migration script, I think the best way to go is:
20:29 < djjuhasz> a) add a --release-120-fix flag
20:30 < djjuhasz> or b) add a separate task like you suggested
20:30 < djjuhasz> e.g. ./symfony propel:release-120-fix
20:30 < djjuhasz> bit of a pain for the users, but I don't think we can help it
20:31 < Sevein> the --release-120-fix flag is for propel:migrate, right?
20:33 < mcantelon> djjuhasz: What happens if the user forgets to include the flag?
20:35 < djjuhasz> we could add a confirm dialog i guess
20:35 < djjuhasz> cuz it will screw up their data
20:35 < Sevein> yep, good idea
20:35 < Sevein> "Are you migrating from ICA-AtoM 1.1?" sth like that
20:35 < djjuhasz> problem is we can't check for a specific database version, it could be anything pre-1.2
20:36 < djjuhasz> Sevein: yep
20:36 * Sevein will update the <a title="XML - EAD export" class="closed_ref" href="/p/qubit-toolkit/issues/detail?id=20"> issue
20 </a>:37 < djjuhasz> in that case maybe we should just have the confirm dialog, and have a --no-cofirm option
20:37 < djjuhasz> or something
20:38 < mcantelon> djjuhasz: Crappy... so there's nothing that was added specifically to the 1.2 schema that would distinguish it from earlier versions...
20:39 < djjuhasz> i don't think so
20:40 < djjuhasz> aside from some menus, but I think that's a poor criteria
20:40 < Sevein> accession stuff...
20:41 < djjuhasz> yeah, but those tables won't show up in yaml unless they have added accession data
20:41 < djjuhasz> which isn't guaranteed
20:41 < Sevein> but terms, taxonomies
20:41 < djjuhasz> oh yeah
20:41 < Sevein> protected terms
20:41 < djjuhasz> that's a good idea
20:42 < Sevein> that's what we talked in the mail thread, checking for 1.1 data before the db version is evaluated
20:42 < Sevein> options to avoid the user painnnnn
20:43 < mcantelon> Yes! The dreaded user pain. :..[
20:43 < Sevein> hehe
20:44 < djjuhasz> still, i think a confirm dialog is a good idea
20:44 < djjuhasz> but the taxonomies check sounds pretty strong
20:44 < Sevein> so you would do both?
20:45 < mcantelon> Good plan... the user as sanity check.