Closed (fixed)
Project:
Drupal core
Version:
8.0.x-dev
Component:
database update system
Priority:
Critical
Category:
Task
Assigned:
Unassigned
Issue tags:
Reporter:
Created:
14 Oct 2015 at 16:09 UTC
Updated:
6 Nov 2015 at 20:34 UTC
Jump to comment: Most recent, Most recent file
Comments
Comment #2
alexpottCreated dumps by:
I guess a test per file would not go amiss.
Comment #3
catchDo we want a new database with similar contents to the beta12 ones?
Or do we want to upgrade the beta12 database to RC1 then dump it?
If there are bugs in the beta12-rc upgrade path which are undiscovered, those could be two different database dumps...
Comment #4
alexpottI guess with the filled dong the steps I did in #2 makes sense - we have to scripts to create all the content because we don't do it like that. But with the bare we should just install standard at RC1 and dump it. I'll re-do the bare dump.
Comment #5
alexpottAdded tests - as there are no updates yet these tests don't show anything but having the dumps tests and ready waiting for the first update hooks will be helpful for issues like #2479487: ImageStyles can be deleted while having dependent configuration.
Also the bare database dump was generated because installing standard at the point of RC1 and dumping the db.
Comment #6
dawehnerOne thing which would be interesting is whether the dump of the DB after beta 12 + update path is basically the same compared to the DB installed on RC1 directly.
Comment #7
effulgentsia commentedEven if this isn't technically Critical until there's some other issue that adds an update function, I still think it makes sense to raise this to Critical now, since we'll have such an issue eventually.
I think it also makes a lot of sense for this to happen before tagging RC2, though if it doesn't, we can retitle it to "Create RC2 database dumps" after tagging RC2.
Comment #8
dawehnerYeah RC1 is now already nearly history.
IMHO we should still keep the old dumps so we ensure that continues update paths are supported, not only to support THIS continues update path.
Comment #9
catchI think we should open a follow-up, possibly meta, to add more database dumps. As we have more releases, we have more possible code paths for updates.
Assuming two weeks in the future and RC3 has been tagged, all of the following are possible:
beta12-rc3
beta12-rc1-rc3
beta12-rc1-rc2-rc3
rc1-rc3
rc1-rc2-rc3
rc2-rc3
Fortunately for us, we no-longer have 7.40->8.0.0-rc3, and hence no 5.2-6.43-7.40-8.0.0-rc3.
There are diminishing returns with trying to test that many upgrade path routes (although really, they don't diminish that much), and for real sites we can tell people to never skip a core release (which reduces the number of permutations above), but it'd be great to get to the point where we can add those permutations more easily.
I think what's here is a good improvement though, and we should get it in as-is.
Comment #10
dawehnerMaybe we could also check that we have the hook_post_update_X() executed as well
Let's not use
SafeMarkup::format()but newFormattableMarkup()Comment #11
jhedstromThis should address #10.
Comment #12
catchBumping this to RTBC.
But we should open a follow-up, before actually committing this, to add scriptable filled database dumps - since otherwise we're stuck with:
1. Only having test coverage for a site starting on beta 12, which is going to be 0.0000001% of actual Drupal 8 sites
2. Having to manually recreate the dump by clicking around if we want anything other than #1.
Comment #14
effulgentsia commentedI opened #2600086: Create a script to generate a filled database dump and use it to replace the pseudo-RC1 one we currently have and pushed #11 to 8.0.x.