[PP-1] Base fields miss out on Views data from hook_field_views_data()

Hi,

Notes that may light somebody.

I found why the default type is string to datetime basefields. In web/core/modules/views/views.views.inc we have a switch that set it how string:

// Expose data for each field property individually.
  foreach ($field_columns as $column => $attributes) {
    $allow_sort = TRUE;

    // Identify likely filters and arguments for each column based on field type.
    switch ($attributes['type']) {
      case 'int':
      case 'mediumint':
      case 'tinyint':
      case 'bigint':
      case 'serial':
      case 'numeric':
      case 'float':
        $filter = 'numeric';
        $argument = 'numeric';
        $sort = 'standard';
        if ($field_storage->getType() == 'boolean') {
          $filter = 'boolean';
        }
        break;

      case 'blob':
        // It does not make sense to sort by blob.
        $allow_sort = FALSE;
      default:
        $filter = 'string';
        $argument = 'string';
        $sort = 'standard';
        break;
    }
...

The datetime field type must not have a valid filter handler defined.

In datetime_type_field_views_data_helper(), in datetime core module, we have a comment that say:

// @todo This code only covers configurable fields, handle base table fields
// in https://www.drupal.org/node/2489476 → .

I think that the problem is the base fields don't have Field Storage.

If I execute:

$fieldStorage = \Drupal::entityTypeManager()
      ->getStorage('field_storage_config');
    $fields = $fieldStorage->loadMultiple();

$fields don't have any base fields.

I realize the status of this is postponed, but the fix for issue as I understand it seemed doable so I opened a MR.

This is what I think the goal of this issue is (correct me if I'm wrong):

If you have a base table (in Drupal speak, apparently this means a table unrelated to any entity) that has a datetime field/column, it should be filterable in views the same way that a timestamp integer field would be. Additionally the datetime field should be displayed in the view the same way that a timestamp field can be displayed.

If that's correct, then the MR does the trick for me.

For example, given this:

/**
 * Implements hook_schema().
 */
function my_module_schema() {
  $schema['my_custom_table'] = [
    'description' => 'A custom table.',
    'fields' => [
      'date' => [
        'type' => 'varchar',
        'mysql_type' => 'datetime',
        'not null' => TRUE,
      ],
    ],
  ];

  return $schema;
}

/**
 * Implements hook_views_data().
 */
function my_module_views_data() {
  // Make my_custom_table table
  // queryable by views.
  $data['my_custom_table'] = [
    'table' => [
      'group' => t('A group'),
      'provider' => t('my_module'),
      'base' => [
        'field' => 'date',
        'title' => 'An example table',
        'help' => 'This is an example table description.'
      ],
    ],
    'date' => [
      'title' => t('A datetime field/column'),
      'help' => t('This is a datetime field/column.'),
      'field' => [
        // ID of field handler plugin to use.
        'id' => 'datetime',
      ],
      'sort' => [
        // ID of sort handler plugin to use.
        'id' => 'datetime',
      ],
      'filter' => [
        // ID of filter handler plugin to use.
        'id' => 'datetime',
      ],
      'argument' => [
        // ID of argument handler plugin to use.
        'id' => 'datetime',
      ],
    ],
  ];
}

I can make a view of "An example table", and add a "A datetime field/column" field and filter.

> If you have a base table (in Drupal speak, apparently this means a table unrelated to any entity)

That is not what base table means. Base table and base field specifically refers to entity base fields to goal is to have them declared automatically viewing any manual views data hooks.

Ah perhaps I'm in the wrong place then. I'll open a different issue. The problem I'm trying to solve is:
1. Views does not support filtering on a datetime database field.
2. Views does not support displaying a datetime database field.