Disallow use of plugins during update

entity_reference_field_schema() uses the entity manager
system_update_8057() uses the action manager

Is entity_reference_field_schema() called during updates ? Eventually it'g going to move to ConfigurableEntityRefetenceItem (a plugin class) anyway.

Well it's in .install, so it could be? I'm not 100% sure if it is. But yes, that's not as much a worry as the action one.

Is entity_reference_field_schema() called during updates ?

It should definitely not be. If it is somewhere, it's a bug that would need to be fixed :)

Oh I was thinking of hook_schema, not hook_field_schema. Ignore me.

So we need to

1. disallow usage of plugins
2. figure out how to do action's upgrade path without them

system_update_8057() is a nice example of why we can't use plugins and their definitions in update functions. And it means our test coverage there is incomplete. Whatever that's doing exactly.. it won't work for disabled modules. Yes, there's the issue to remove that concept, but still, discovering plugin definitions could possibly invoke derivate classes and stuff like that, and that might explode in really bad ways.

So whatever that's doing there, we'll just have to hardcode it. We had similar issues with cache tables, see update_add_cache_columns() in update_prepare_d8_bootstrap(). And provide a way to contrib to do what they have to do with their action-thingies.

However, that's just the obvious one. There are going to be nastier cases, let's assume the stream wrapper plugin issue get's in. Right now that hook is tied down to system.module in UpdateModuleHandler. I expect we will have to do something similar in the plugin version and return a hardcoded set of definitions.

If disabled modules go away, I'm not really sure why we bother with "don't use regular runtime APIs", TBH ?

@yched: it's always the same problem: you cannot run new APIs on an older database.

That said. If fields are plugins, I would really recommend not doing that. Not being able to manipulate fields and entities in update functions is going to be a major PITA for code-driven workflows.

Speaking out loud, maybe we could differentiate "major" update functions and "minor" update functions. We run all the major update functions first, with most of the API disabled, then we run the minor ones. It is a fatal error to try to run the update process on a site that has first minor updates, then major updates to run (which is the equivalent of "update your Drupal 7.x site to the last minor version first, then run the upgrade path to Drupal 8).

It's already a timebomb to use the entity API in update functions in 7.x, as it relied (and still does) on the schema for loading and saving the data. If the schema is different, kaboom. I'd prefer it blowing up rather than having to fix update functions month later when you change it again... *that's* the real PITA.

#8-#10 - I've also been thinking lately that by disabling hooks on updates, we'be only been considering hook_update_N() as the db upgrade tool for core or contrib.
But update.php was also typically the tool used for site-specific housekeeping or drupal-related post deploy scripts. "write your stuff as updates in the custom [sitename].module, it'll be played with the rest in update.php".
Those have nowhere to go now. This can be replaced with drush scripts, but there is no existing framework to automate execution / sequencing, so it will be each site/shop re-inventing its own. And there most certainly are small-ish sites that do not use drush.

#11: unless drush is included with core, it cannot be required.

Er, what?

While I can understand the need to have a restricted environment for a D7-D8 update, tons of people use update hooks for routine deployment tasks already. Blocking hooks blocks node save, so they're barely useful. If we remove plugins, too, then we may as well remove the update system as an actual system and just ship a D7->D8 stand-alone database script, and tell people that for deployment tasks they're on their own.

At this point we've castrated the update system to be barely worth having.

(This topic came up at a recent Chicago DUG meeting, and we had an entire room of Drupal developers going "um, so now what do we do?")

@Crell: see #13 that makes exactly the same point, and have a suggested way forward.

As a side note: migrations in mature frameworks (the one I have in mind is Active Record from Ruby on Rails) are also totally banned from using generic API functions, for exactly the same reasons that we are disabling hooks here.

Tagging all critical D8 upgrade path issues as "beta blocker."

Just to get something moving.