Closed (works as designed)
Project:
Drupal core
Version:
8.4.x-dev
Component:
content_moderation.module
Priority:
Normal
Category:
Task
Assigned:
Unassigned
Reporter:
Created:
28 Jun 2017 at 05:55 UTC
Updated:
19 Oct 2017 at 08:18 UTC
Jump to comment: Most recent, Most recent file
Comments
Comment #2
sam152 commentedComment #3
sam152 commentedInitial start of this with @jhedstrom approach from #2846618: Unofficial content_moderation 8.2.x to 8.3.0 upgrade path.
I couldn't get this test to pass. Just running this approach I get:
I tracked this down to the indexes the issue introduced being missing.
If I try and use the update manager to update the entity definition, it says the field needs to be updated, despite running updateFieldStorageDefinition.
Comment #4
sam152 commentedI've had another look at this. I managed to come up with quite a hideous patch (with code pulled from a few sources) which doesn't seem to leave any pending entity updates, ensures the new indexes exist and changes the column size.
My guess is the entity update manager will never change the column size of a table that already has data, so it has to be done manually. The ->applyUpdates is needed to create the indexes, which is has no problem doing (could possibly be made more specific, only update our entity type).
Schema before update:
Schema after:
Comment #6
mstef commentedTesting with 8.3.4. Patch applies cleanly and everything seems to be working. I'll continue testing.
Thank you very much for your work.
Comment #7
fgmWith this patch applied:
* drush updb --entity-updates applies cleanly
* but then drush entup throws:
Comment #8
rop commentedAfter applying the patch
drush updb --entity-updatesstill throws:
Comment #9
sam152 commentedFor some reason composer patches wont apply a patch correctly if it only contains new files. Adding an empty newline to the module file seems to fix things. I was getting the patch files in ./core/core/modules instead of the correct ./core/modules path.
Comment #10
sam152 commentedComment #11
fgmThe upgrade path passes like a charm now, and the data look as expected. Thanks for the impressive work.
The most worrying part for me is the fact that this introduces
content_moderation_update_800[1-3]()implementations, which might cause conflict when the module leave experimental status and official versions of these same functions start appearing. But so for, none exist in 8.3.3/8.3.4/8.3.5.Comment #12
sam152 commentedYou're welcome!
The instructions in #2846618: Unofficial content_moderation 8.2.x to 8.3.0 upgrade path say to dial back your schema version by using
drush ev "drupal_set_installed_schema_version('content_moderation', 8000);".It'd be great if someone had time to organise the instructions into the meta and make sure they were referenced from each issue summary.
Comment #13
damienmckennaJust to voice my concern - not having an upgrade path between minor versions is one thing, but making architectural changes that result in broken configuration and/or data without providing the necessary update scripts is a pretty user-hostile decision. Huge thanks to everyone working on this update script.
Comment #14
rop commentedI've tried the patch again, but it does not seem to fix the problem, as mentioned before.
I could be doing something wrong.
My situation is: I've started using content_moderation in 8.2.6 , I've then updated core successfully to core version 8.3.2 using the relevant patch from this (parent)issue. That worked fined. After this I've update core to 8.3.4 but despite apllying patch#9 I keep getting the errors about too long keys. (I've also tried 8.3.3)
The patch applies fine, it asks to overwrite the existing files, yet drush entity-updates fails.
Anyone an idea why it fails while others are succesfull?
Comment #15
fgm@roproprop : You need to run drush updb first. After that there remains nothing to update for drush entup.
Comment #16
gábor hojtsyRe @DamienMcKenna:
Well, the goal with experimental modules is to move faster, which by definition means breaking things. Its like an 8.x-1.x-dev of a contrib module, anything may change. If developers would write an upgrade path then they would need to provide an upgrade path test (data dumps, etc), so moving fast is not really feasible anymore. What distinguishes experimental modules from non-experimental modules then? The only difference between a 8.x-1.x-dev contrib module and an experimental module in core now is where it is.
(Whether this is a good idea is a different question, but if the documentation or the warnings when enabling or having experimental modules enabled lead you to believe otherwise, then we need to fix those for sure).
Comment #17
xjmComment #18
xjmComment #19
rop commented@fgm I did run
drush updbfirst. After that status still says entities need to be updated.I've now tried again doing only
drush updband I again get these errors:Comment #20
sam152 commentedComment #21
sam152 commentedYour schema version is at 8001 instead of 8000, you need to make sure 8001 runs by rolling it back. See the updated issue summary.
Comment #22
rop commented@Sam152 Thank you! that did the trick..all good now.
Sorry for the confusion.
Thanks for your work on this.
Comment #24
sam152 commented