DOCS: Explain shareAcrossTables/Fields in more depth

[alexander-nitsche-governikus]

Hi Nikira, hi content blocks team,

thanks a lot for your work. I am currently reading into nested content elements and have problems to understand the shareAcrossTables/Fields section:

If Collection fields of a Content Block pointing to the same foreign_table should have the property shareAcrossFields to be set, why is this optional? What is happening behind the scenes? What are the scenarios to not set it?

The same holds for shareAcrossTables.

Having it understood i will be happy to update the corresponding chapter.

Greetings
Alex

[nhovratov]

@alexander-nitsche-governikus Thanks for asking!

It is an opt-in setting, because I want the user to intentionally set this option, if the need arises. In context of nested Content Elements, both options will most likely be needed at some point. But in some cases don't. This is why I recommend to set them, if you are unsure.

Behind the scenes, a new database field will be created for each option. One to distinguish the table context and one to distinguish the field context. If you don't need those fields, they are in fact redundant. Many developers don't like redundancy in their database.

Some more history: During development, I first introduced anonymous Collection (without foreign_table). These Collection don't ever need these two reference fields (because they can only be the child where they are defined). Only later I added these two options, when support for foreign_table was added.

So, yeah this is kind of a trap if you want to have Collections for the same table across multiple fields/tables later on during development. But it's also not impossible to fix it, when you are able to do some SQL queries.