? ?
avatar sakiss
sakiss
30 Jul 2020

Problem identified

The table #__fields_values is not normalized.
In simple words we have repetition of information (value) between this table's rows and the #__fields table.
field_values

The inserted values seem to be stored as a json string in the fieldparams column of the #__fields table

{"multiple":"","options":{"__field10":{"name":"Computer Science","value":"Computer-Science"},"__field11":{"name":"History","value":"History"},"__field12":{"name":"Poltics","value":"Poltics"}}}

This is jeopardising the referential integrity of the data, as the only responsible for that, is the code used for saving them.
E.g. If we made a change in a value, this change has to be reflected in all the tables, where that value is present.

Proposed solution

Create 1 more table for the values, where each value will be saved and will have a primary key.
Then use the PK as a foreign key to the table _#_fields_values (or wherever they are used).

Open questions

This requires changes in the code level beyond the schema changes. Is this a long shot atm?
Not sure if it will cause any B/C issue or any other issue (e.g. with the plugins).
I can prepare a PR for that, in case you agree in principle.

avatar sakiss sakiss - open - 30 Jul 2020
avatar joomla-cms-bot joomla-cms-bot - change - 30 Jul 2020
Labels Added: ? ?
avatar joomla-cms-bot joomla-cms-bot - labeled - 30 Jul 2020
avatar joomla-cms-bot joomla-cms-bot - labeled - 30 Jul 2020
avatar sakiss sakiss - change - 30 Jul 2020
The description was changed
avatar sakiss sakiss - edited - 30 Jul 2020
avatar sakiss sakiss - change - 30 Jul 2020
The description was changed
avatar sakiss sakiss - edited - 30 Jul 2020
avatar sakiss sakiss - change - 30 Jul 2020
The description was changed
avatar sakiss sakiss - edited - 30 Jul 2020
avatar sakiss sakiss - change - 30 Jul 2020
The description was changed
avatar sakiss sakiss - edited - 30 Jul 2020
avatar sakiss sakiss - change - 30 Jul 2020
The description was changed
avatar sakiss sakiss - edited - 30 Jul 2020
avatar sakiss sakiss - change - 30 Jul 2020
The description was changed
avatar sakiss sakiss - edited - 30 Jul 2020
avatar sakiss sakiss - change - 30 Jul 2020
The description was changed
avatar sakiss sakiss - edited - 30 Jul 2020
avatar sakiss sakiss - change - 30 Jul 2020
The description was changed
avatar sakiss sakiss - edited - 30 Jul 2020
avatar laoneo
laoneo - comment - 31 Jul 2020

A pr would be good, but you have to do it for J4.

avatar Bakual
Bakual - comment - 31 Jul 2020

That would only work for fields which have predefined values (eg lists, checkboxes), right?
Fields like text or number don't have a reference that could be used.

I'm also not really convinced that the stored values need to be updated if you change the field options. Those field values are not meant to have referential data integrity. That's not the purpose of those fields.

Appendum:

  • The #__fields table contains the definition of the field. For eg list fields that means also defining the options used in that field and thus also its possible values. It also contains the mapping from a stored value to the human readable display text. It's also stored in a JSON string, which means it's absolutely not meant to be processed by the DB itself.
  • The #__fields_values table on the other hand contains the stored values. From a DB normalisation view, it's not the same information.
avatar sakiss sakiss - change - 31 Jul 2020
Status New Closed
Closed_Date 0000-00-00 00:00:00 2020-07-31 09:26:51
Closed_By sakiss
avatar sakiss sakiss - close - 31 Jul 2020
avatar sakiss
sakiss - comment - 31 Jul 2020

I am closing it as the fields scope seems to be broader than i initially thought.
I will reconsider that.

Add a Comment

Login with GitHub to post a comment