_update_8003_field_create_field() relies on field schemas never changing and plugins being available

I think we should avoid that getSchema() call down there. That's almost like a hook, always was, we just never named it like that, so it still works.

My suggestion would be to make an update path version of that function that expects the field schema as an argument.

It's ugly. But updating will always be ugly, even with enabled modules. We don't load .module files, we might at some point decide that we can no longer load plugins/services, even for enabled modules, as they might do stuff that the partially upgraded site can not yet do.

My suggestion would be to make an update path version of that function that expects the field schema as an argument.

Yes agreed, that's all we can do.

Marking this 'needs more info'. We shouldn't be loading plugins/services for modules within the upgrade path, if we do, then we should find a way to stop that.

https://api.drupal.org/api/drupal/core!modules!field!field.install/funct...

This is the same problem with module schemas - if the field schema changes once head2head updates are supported, then the update will be run with two different schema definitions and subsequent updates can't rely on it. For modules we introduced hook_schema_0() so that when the module is first installed in an update, it's done so with a predictable schema.

It's even worse than that though with fields, because creating a field can happen at any time - it's not just about enabling a module for the first time. So I have no idea how to deal with that.

This was how the helper function worked in D7 - called hook_field_schema() directly.
Now, of course, the schema() method is in a plugin class, we need to load it (it's a static method though, so no object instanciation needed)

I'm not sure we can do anything with the assumption that the plugin system cannot be used in updates. There's code in there we need to access in updates.

Yeah we got around it with some trickery in #1907960: Helper issue for "Comment field" see https://drupal.org/files/decouple-comment-node-731724.332.interdiff.txt

I'm not sure we can do anything with the assumption that the plugin system cannot be used in updates. There's code in there we need to access in updates.

For every other situation like this in core, we copy the code over, why's that not possible here?

Removing pointless tag.

For every other situation like this in core, we copy the code over, why's that not possible here?

In this case this would mean either having the caller of _update_8003_field_create_field() provide the field schema, and either:
- modify the calling stack so that field_sql_storage functions accept an injected schema rather than fetching the schema themselves
- not call field_sql_storage functions and duplicate the whole table creation logic in _update_8003_field_create_field() [note: that's 100+ lines - see _field_sql_storage_schema()]

Both seem a little overkill to support the case of "module providing the field type might be disabled", which we're not supposed to support anyway after "disabled modules" are killed ?

Hm. So, as the fine folks in #731724: Convert comment settings into a field to make them work with CMI and non-node entities have found out in their workaround for this:

$field = new Field(array
  'name' => 'foo', 
  'type' => 'text',
  ...
  'schema' => array(...), // an injected, hardcoded schema array
));

results in the protected $field->schema property being set to the injected schema array.
Since $field->getSchema() (called by field_sql_storage when creating the tables) basically does:

if (!isset($this->schema)) {
  $this->schema = (call $field_type_class::schema($field))
}
return $this->schema;

then the injected schema just wins, without needing to access the field type class.

So, yes, passing a hardcoded field schema in _update_8003_field_create_field() should "just work" currently. It's just that this only happens to work by chance and was never an intended behavior. I guess we'd need to make that explicit somewhere so that it doesn't get broken later on...

We should also break it explicitly for enabled modules. As explained by @catch, an update function must not rely on plugins.

Patch
- makes 'schema' required in _update_8003_field_create_field()
- adds it for existing calls
- adds a test to ensure that injection of an explicit schema in a Field config entity works.

Opened #2055605: Disallow use of plugins during update.

Committed/pushed to 8.x, thanks!