Problem/Motivation
The post update workspaces_post_update_move_association_data()
makes an entity schema change. It deletes the workspace_association entity.
Generic entity type operations in hook_update_N implementations cannot depend on this update because it's a post update. If they are checking something on all entity types then the workspace_association entity type is completely invalid because neither the storage nor the entity type class exist.
As a whole workspaces_post_update_move_association_data()
itself cannot be a hook_update_N because it is saving revisions.
Proposed resolution
Move the entity type deletion to an update hook so updates can depend on it.
Remaining tasks
User interface changes
API changes
Data model changes
Release notes snippet
Comment | File | Size | Author |
---|---|---|---|
#9 | 2-8-interdiff.txt | 1.7 KB | alexpott |
#8 | 3099986-8.patch | 4.81 KB | alexpott |
#8 | 2-8-interdiff.txt | 1014 bytes | alexpott |
#2 | 3099986-2.patch | 4.63 KB | alexpott |
Comments
Comment #2
alexpottComment #3
alexpottComment #4
alexpottThere is part of me that thinks maybe this is a hard problem. Any update that does generic operations on entity types is going to need to think about this. Maybe an alternative if for updates that do generic operations on all entity types to be more robust. Like at least check if the entity type class exists. I'm very not sure. It seems impossible for generic entity type updates to really work reliably. Hmmmm.
Comment #5
amateescu CreditAttribution: amateescu for Pfizer, Inc. commentedI don't think it's common practice to put @see comments in the doxygen block of update functions. I guess it won't end up in the text displayed to the users on the update screen because we only show the first line there, but it's still weird to have it there..
We need to delete the state entry here and below where we drop the workspace_association tables.
It would be good to move this comment over to the new
workspaces_update_8803()
function.Comment #6
amateescu CreditAttribution: amateescu for Pfizer, Inc. commentedOn the other hand, you're right in #4 that update functions that go through each entity type have to very very careful, because a contrib module for example wouldn't be so strict with an update like this one.. so I'm not sure this patch buys us anything in the end :)
Comment #7
alexpottOne argument is favour of this change is that if you did hit this problem on your site at the moment you have no way of fixing it. With this patch you could use hook_update_dependencies() to force an update order and get around the problem.
I think there's no getting around the fact that
but there doesn't mean we shouldn't arrange core updates to be as helpful as possible is your site breaks because of this complexity.
Comment #8
alexpottAddressing #5
Comment #9
alexpottNow with the correct interdiff...
Comment #10
amateescu CreditAttribution: amateescu for Pfizer, Inc. commentedThanks for the update, looks ready to go now :)
Not sure about the Major priority though, the problem is only theoretical at the moment and it covers only a very narrow list of update functions, so I'd be inclined to demote it to Normal, but the committer who will review this can decide to do that.
Comment #11
catchSo I agree we should do the schema change in hook_update_N() for the couple of reasons given above, but I'm wondering why we don't move the rest of the post update into the hook_update_N() and empty it out?
Comment #12
alexpott@catch because it contains an entity save and we have no guarantees about the entity storage system working while hook_update_N is running.
Comment #16
catchAhhh couldn't see it in the patch context but should've checked the actual update.
Committed/pushed to 9.0.x/8.9.x/8.8.x, thanks!