[#46722] - Joomla Fields not using primary key [J3 to J6]
- Closed
- 20 Jan 2026
- Medium
- Build: 5.4.1
- # 46722
Hello, ever since Joomla fields for articles, users or other parts were introduced in Joomla 3, the tables are missing primary and unique keys. (on J3 to J6)
Example:
#__fields_categories
#__fields_values
This makes it very ineffecient to update any values in these tables especially on heavily visited sites. If a table is missing primary unique key and Joomla erases all datas before they are inserted again, this can lead to table locks and huge slowdown and data inconsitency during this operation while there are other threads reading the same datas. In extreme case where select's are prefered by mysql engine over delete/insert, the queries using this table might get locked indefinitely. It is also not clear how this can influence real-time replication since there is no unique key on the table.
My suggestion is to add primary keys to all tables where they are missing and make sure that there is no "delete all + insert" within Joomla core code.
Best Regards, Stan
| Labels |
Removed:
?
|
||
joomla-cms-bot
- | Labels |
Added:
No Code Attached Yet
|
||
| Status | New | ⇒ | Closed |
| Closed_Date | 0000-00-00 00:00:00 | ⇒ | 2026-01-20 16:46:44 |
| Closed_By | ⇒ | Fedik |
| Labels |
Added:
Performance
|
||
Hello, the discussion is over a year old and has no final resolution and it talks about extending the table with other fields which are not really necessary in my opinion currently (or related to the bug itself).
I had filed a BUG here - in my opinion this is a large architecture issues that can cause both performance problems as well as data corruption on busy sites.
I believe the only thing that really needs to be done is to add "primary autoincrement unique key" (id) and adjust the code to use the ID for updates/deletes whenever possible.
Imaging MCP server quickly and concurrently creating custom fields per com_content articles - upon each new field value added all of the article's values have to be dropped... (it does not take many tries to corrupt the table with concurrent delete/inserts)
Imagine user's security keys stored in the user's custom fields and clicking save - during the delete/insert, user's keys are not present and thus this can be described as a security issue as well.
Best Regards, Stan
It is a known issue kind of.
No reason to keep two the same opened topics. In my opinion.
We already have a discussion for that:
but, thanks for reaport.