[PP-1] Consider not storing the ComponentTreeStructure data type as a JSON blob

Would it be possible to document what are the benefits and downsides of using a flat table over a JSON blob? Based on the issue summary, it isn't clear to me what are the trade-offs involved in this decision.

Wim Leers → credited longwave → .

Thoughts:

• I agree a JSON blob is overkill and a table is in principle sufficient.
• … but Drupal's Entity Field system assumes every field prop corresponds to a data type (true here too), and that data type must be a single column in the database (not true here), and is always a primitive (the data type class must implement \Drupal\Core\TypedData\PrimitiveInterface if that data type is used for a field property — AFAICT)
• So then IMHO the question becomes: how do we store such a table in a single DB column?

The only exception I can think of (right now, in the little time I have this morning while writing this up to ensure we follow through!): the PathItem field type, which essentially is a computed field type that stores its data in another database table and does the necessary additional DB queries.

Maybe that can work? That maybe actually gets closer to @effulgentsia's original proposal at ✨ JSON-based data storage proposal for component-based page building Active , where he proposed to do some deduplication stuff that most of us wanted to defer to later?

We could then literally have a single DB table for all XB uses, by expanding the columns from

parent,slot,delta,uuid,component

(@longwave's comment)
to:

entity_type_id,entity_id,field_name,parent,slot,delta,uuid,component

… which would not violate the 3.2.4 Facilitating `component props` changes section in docs/data-model.md.

One benefit is this becomes trivial:

An upgrade path for a `component` would require logic somewhat like this:

1. SQL query to search the _tree_ JSON blob for uses of this `component`, capture the UUIDs.

SELECT uuid FROM table WHERE component = "provider:person-card"

@Wim Leers additional note: we also have to consider langcode for asymmetric translations

@lauriii One of the advantages here is it would (at least partially) solve the same problem of non-portable JSON queries (which are already in the XB code base) that 📌 Calculate field and component dependencies on save and store them in an easy to retrieve format Active is also trying to remove - same general problem as #5.

… but Drupal's Entity Field system assumes every field prop corresponds to a data type (true here too), and that data type must be a single column in the database (not true here), and is always a primitive (the data type class must implement \Drupal\Core\TypedData\PrimitiveInterface if that data type is used for a field property — AFAICT)

I'm not sure exactly which data isn't fitting in a single column, but could just that column be JSON (storing a flat array of whatever doesn't fit) without undermining the goal of the issue?

#5++

#6++

#7: an XB field must store a tree of components + sources for their props values. This issue proposes to store that tree as a list, so not as a single column in a single row, but as multiple columns in multiple rows. That's what I was trying to convey in #4, and is also why I pointed to @effulgentsia's "deduplication" proposal (we could implement this by storing a single value for each XB field revision's tree, with that value pointing to a foreign key in another table, where @longwave's proposed columns could then be used).

I think this proposal makes sense. My initial thinking behind JSON for this was thinking we wanted to store it as a tree. But since we've already changed that to a flat JSON representation, I don't think JSON for this part has any special value.

Drupal's Entity Field system assumes every field prop corresponds to a data type and that data type must be a single column in the database

I think what we could do is store this as a multi-valued field. If we want to keep tree and values as a single field, we could do that by each item containing the following columns: component_instance_id, component, parent, slot, delta_in_slot, props, where that last one is the JSON props source/expression/values for that component instance.

However, at some point, I think it will make sense for us to model this as two fields: in other words, pull the props column out of the above suggestion and make it its own separate field from the field representing the tree. Not sure if we want to jump to the two field implementation as part of this issue or continue to keep it as one field until we separately discuss the pros and cons of two fields vs one.

#4

We could then literally have a single DB table for all XB uses, by expanding the columns from

entity_type_id,entity_id,field_name,parent,slot,delta,uuid,component

I'm not sure that would with revisions and sync/async translations?

Removed duplicate related item.

I incorporated this into 📌 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 .