Field type config schemas are not in the base schema

I did that based on other examples, it looks very weird to me as well but something else didn't work ?

I also included the string schema in #2068655: Entity fields do not support case sensitive queries as I had to change text there. Will conflict with that but I don't really care what gets in first.

Also, it should be possible to verify this by adding the schema trait stuff to the ContentTranslationSettingsTest. That exploded badly without this and should pass with these fixes.

+++ b/core/config/schema/core.data_types.schema.yml
@@ -402,7 +402,13 @@ core.date_format.*:
+field.string.storage_settings:
+  type: sequence
+  label: 'String settings'
+  sequence:
+    - type: string

I think this should be:

field.string.storage_settings:
  type: mapping
  label: 'String settings'
  mapping:
    max_length:
      type: integer
      label: 'Maximum length'

1. +++ b/core/config/schema/core.data_types.schema.yml
   @@ -422,7 +428,143 @@ field.string.value:
   +field.string_long.storage_settings:
   +  type: sequence
   +  label: 'String (long) settings'
   +  sequence:
   +    - type: string
   

   This should just be of the type: field.string.storage_settings

2. +++ b/core/config/schema/core.data_types.schema.yml
   @@ -422,7 +428,143 @@ field.string.value:
   +field.string_long.field_settings:
   +  type: sequence
   +  label: 'String (long) settings'
   +  sequence:
   +    - type: string
   +      label: 'Setting'
   

   Use type: field.string.field_settings - actually string has no field settings afaics

3. +++ b/core/config/schema/core.data_types.schema.yml
   @@ -422,7 +428,143 @@ field.string.value:
   +field.uri.storage_settings:
   +  type: sequence
   +  label: 'URI settings'
   +  sequence:
   +    - type: string
   

   Similar to string this just has a max_length integer value

4. +++ b/core/config/schema/core.data_types.schema.yml
   @@ -422,7 +428,143 @@ field.string.value:
   +field.uri.field_settings:
   +  type: sequence
   +  label: 'URI settings'
   +  sequence:
   +    - type: string
   +      label: 'Setting'
   

   There are no uri field settings.

5. +++ b/core/config/schema/core.data_types.schema.yml
   @@ -422,7 +428,143 @@ field.string.value:
   +field.created.storage_settings:
   +  type: sequence
   +  label: 'Created timestamp settings'
   +  sequence:
   +    - type: string
   ...
   +field.created.field_settings:
   +  type: sequence
   +  label: 'Created timestamp settings'
   +  sequence:
   +    - type: string
   +      label: 'Setting'
   

   There are no created field settings or storage settings. Tempting to just set these to type: ignore - or somehow fix the field config entities to not export the empty array.

6. +++ b/core/config/schema/core.data_types.schema.yml
   @@ -422,7 +428,143 @@ field.string.value:
   +field.changed.storage_settings:
   +  type: sequence
   +  label: 'Changed timestamp settings'
   +  sequence:
   +    - type: string
   ...
   +field.changed.field_settings:
   +  type: sequence
   +  label: 'Changed timestamp settings'
   +  sequence:
   +    - type: string
   +      label: 'Setting'
   

   Exactly the same as created. There are none.

base field overrides (which seem to be singular and not multivalued in defaults).

That assumption is not correct, base fields can be multi-valued (they do need custom storage for that now, though) and could have multiple default values. But I've noticed this as well.

It's not just the multi vs. single value. The problem is also that the schema defines properties, like 'value' and default values are most of the time specified as scalar, as the entity field api takes care of expanding that to the main property of the first field item.

We probably need to convert it internally at some point, similar to how we expand it during setValue(). So 'whatever' needs to become array(array('value' => 'whatever')). Also note that 'value' is not hardcoded but should be derived from the main property name method of the specified field type.

multi or single values is not field type specific. All field types can have multiple values theoretically and that is why the schema/default value.

The problem is that you need to go from this:

$entity_reference_field_defininition->setDefaultValue(1);
$integer_field_definition->setDefaultValue(1);

To the correct structure, which would be:

entity reference: array(0 => array('target_id' => 1)
integer: array(0 => array('value' => 1)

The reason setDefaultValue(1) works is that $entity->$field = 1, works as well, and it basically has the following logic:

1. In FieldItemList::setValue(), we have this:

// Support passing in only the value of the first item.
      if (!is_array($values) || !is_numeric(current(array_keys($values)))) {
        $values = array(0 => $values);
      }

2. In FieldItemBase::setValue():

    // Treat the values as property value of the first property, if no array is
    // given.
    if (isset($values) && !is_array($values)) {
      $keys = array_keys($this->definition->getPropertyDefinitions());
      $values = array($keys[0] => $values);
    }

This is actually not correct, instead of just using the first property, it should use $definition->getFieldStorageDefinition()->getMainProperty(), which would return value/target_id.

What I would try is add similar logic to BaseFieldDefinition::setDefaultValue(), but it might be easier to reverse it: First if you do not have an array, convert it to array($main_property => $value), and second if the first array key is not numeric, convert it to array(0 => $value).

Yes. And it might be easier to already convert it to multiple in the base field definition and not just the override, so you don't have the additional complexity there when comparing and so on.

+++ b/core/config/schema/core.data_types.schema.yml
@@ -449,8 +574,7 @@ field.boolean.storage_settings:
+  type: sequence

I guess, this will fail. we need to provide element under sequence.

+++ b/core/lib/Drupal/Core/Field/BaseFieldDefinition.php
@@ -443,6 +443,12 @@ public function setDefaultValueCallback($callback) {
+    if (!is_array($value)) {
+      $value = array(array($this->getMainPropertyName() => $value));
+    }
+    elseif (!is_numeric(array_keys($value)[0])) {
+      $value = array(0 => $value);
+    }

Not else if, just two separate ifs.. Both checks need to be applied if you pass in "1".

+++ b/core/lib/Drupal/Core/Field/BaseFieldDefinition.php
@@ -443,6 +443,12 @@ public function setDefaultValueCallback($callback) {
   public function setDefaultValue($value) {
+    if (!is_array($value)) {
+      $value = array(array($this->getMainPropertyName() => $value));
+    }
+    elseif (!is_numeric(array_keys($value)[0])) {
+      $value = array(0 => $value);
+    }

We should probably document somewhere what formats are supported here?

Looks good.

+++ b/core/config/schema/core.data_types.schema.yml
@@ -434,7 +439,127 @@ field.string.value:
+      mapping:
+        target_id:
+          type: integer
+          label: 'Value'

Hmmm... I don't think this can be an integer - should be a string since entity IDs do not have to be an integer. We are also missing the 'target_uuid' key. Other than that looks awesome.

Actually let's handle #40 in a critical follow since this is just moving the definition into core and this patch unblocks discovering other schema issues.

This issue addresses a critical bug and is allowed per #2350615: [policy, no patch] What changes can be accepted during the Drupal 8 beta phase?. Committed 8f89d7b and pushed to 8.0.x. Thanks!