Contrib.social

[PP-1] Use JSON schema type for sqlite and remove text workaround

Open on Drupal.org →
Created on 24 April 2025, 23 days ago

Overview

ComponentTreeItem has the following @todo/workaround. I can't find an Experience Builder issue for this.

    'tree' => [
          'description' => 'The component tree structure.',
          'type' => 'json',
          'pgsql_type' => 'jsonb',
          'mysql_type' => 'json',
          // @todo Change back to 'json' once https://www.drupal.org/i/3487533 is resolved.
          'sqlite_type' => 'text',
          'not null' => FALSE,
        ],
        'inputs' => [
          'description' => 'The inputs for each component in the component tree.',
          'type' => 'json',
          'pgsql_type' => 'jsonb',
          'mysql_type' => 'json',
          // @todo Change back to 'json' once https://www.drupal.org/i/3487533 is resolved.
          'sqlite_type' => 'text',
          'not null' => FALSE,
        ], 'tree' => [
          'description' => 'The component tree structure.',
          'type' => 'json',
          'pgsql_type' => 'jsonb',
          'mysql_type' => 'json',
          // @todo Change back to 'json' once https://www.drupal.org/i/3487533 is resolved.
          'sqlite_type' => 'text',
          'not null' => FALSE,
        ],
        'inputs' => [
          'description' => 'The inputs for each component in the component tree.',
          'type' => 'json',
          'pgsql_type' => 'jsonb',
          'mysql_type' => 'json',
          // @todo Change back to 'json' once https://www.drupal.org/i/3487533 is resolved.
          'sqlite_type' => 'text',
          'not null' => FALSE,
        ],

The core issue hasn't had an update for six months, seems like the priority could be increased from 'normal'. But also there needs to be a tracking issue for XB to update this code once it's fixed. That will probably requires a dependency on the minor release that fixes the bug, unless we determine it can be fixed in a patch release of core.

Proposed resolution

User interface changes

🐛 Bug report
Status

Active

Version

0.0

Component

Data model

Created by

🇬🇧United Kingdom catch

Live updates comments and jobs are added and updated live.
Sign in to follow issues

Comments & Activities

  • Issue created by @catch
  • Comment 23 days ago →
    🇧🇪Belgium wim leers Ghent 🇧🇪🇪🇺

    Those @todos date back to the earliest PoCs, when we didn't have a single d.o issue yet! Yes, many parts of XB are unchanged from the early PoCs. 😅

    Just to make sure: if 📌 Refactor the XB field type to be multi-valued, to de-jsonify the tree, and to reference the field_union type of the prop values Active happens, you agree we wouldn't need to do this, right?

  • Comment 23 days ago →
    🇬🇧United Kingdom catch

    I think that issue would still result in a JSON column to store the field values.

    From the current issue summary:

    data_sources (json): The sourceTypes and expression portion of what's currently in the props column (prior to this proposed refactoring) for this component instance. For example:

    static_values (json): The value portion of what's currently in the props column (prior to this proposed refactoring)

    Or see option #3 "Field Union JSON" from the issue summary of ✨ JSON-based data storage proposal for component-based page building Active .

    The reason for this being that it's a single field type, and that field type needs to be able to handle the equivalent of compound field API fields, and we wouldn't want 'value_1', 'value_2', 'value_3' etc. columns (brings back memories of flexinode).

    So column-per-component doesn't eliminate JSON, it only eliminates a lot of the nesting, and allows individual components to be accessed without parsing them out of the JSON tree when that might be necessary (as discussed in the alternative rendering issue).

    So even though what's in the JSON field would be smaller, it would still be a JSON field, so need similar treatment.

contrib.social Blog FAQ Discussions
Production build 0.71.5 2024