I wasn’t aware of that plugin - that’s neat! I don’t have it installed, but I’m able to enter the data container and run queries though.
That’s a great clue! If I’m reading the error message correctly though, I don’t think it’s on the theme_fields table as that particular table doesn’t have a theme_field_id. I haven’t checked the source code, but I would hazard a guess that the first argument to add_index() is the table name and the second is the column.
Based on that, it looks like it would be the javascript_caches table.
== 20230817174049 EnsureJavascriptCacheIsUniquePerTheme: migrating ============
-- remove_index(:javascript_caches, :theme_id)
-> 0.0208s
-- add_index(:javascript_caches, :theme_id, {:unique=>true})
-> 0.0079s
-- remove_index(:javascript_caches, :theme_field_id)
-> 0.0026s
-- add_index(:javascript_caches, :theme_field_id, {:unique=>true})
So I checked the structure of that table and it has the theme_field_id column:
discourse=# \d javascript_caches
Table "public.javascript_caches"
Column | Type | Collation | Nullable | Default
----------------+-----------------------------+-----------+----------+-----------------------------------------------
id | bigint | | not null | nextval('javascript_caches_id_seq'::regclass)
theme_field_id | bigint | | |
digest | character varying | | |
content | text | | not null |
created_at | timestamp without time zone | | not null |
updated_at | timestamp without time zone | | not null |
theme_id | bigint | | |
source_map | text | | |
Indexes:
"javascript_caches_pkey" PRIMARY KEY, btree (id)
"index_javascript_caches_on_digest" btree (digest)
"index_javascript_caches_on_theme_field_id" btree (theme_field_id)
"index_javascript_caches_on_theme_id" btree (theme_id)
Check constraints:
"enforce_theme_or_theme_field" CHECK (theme_id IS NOT NULL AND theme_field_id IS NULL OR theme_id IS NULL AND theme_field_id IS NOT NULL)
Foreign-key constraints:
"fk_rails_58f94aecc4" FOREIGN KEY (theme_id) REFERENCES themes(id) ON DELETE CASCADE
"fk_rails_ed33506dbd" FOREIGN KEY (theme_field_id) REFERENCES theme_fields(id) ON DELETE CASCADE
I was able to query that table (with the content fields shortened so I could actually read it) and I can see the duplicates. But I’m not sure what the implication of these duplicates are.
discourse=# select id, theme_field_id, digest, substring(content from 1 for 64) as content_64, created_at, updated_at, theme_id, substring(source_map from 1 for 64) as source_64 from javascript_caches where theme_field_id = 3;
id | theme_field_id | digest | content_64 | created_at | updated_at | theme_id | source_64
----+----------------+------------------------------------------+------------------------------------------------------------------+----------------------------+----------------------------+----------+------------------------------------------------------------------
1 | 3 | d0b6ec642d5649064ff0501cadc775a9217b16e0 | "define"in window&&define("discourse/theme-3/initializers/theme- | 2019-02-25 01:26:56.606537 | 2023-08-18 20:47:19.596923 | | {"version":3,"sources":["discourse/initializers/theme-field-3-co
2 | 3 | 7fd74ecf4448afccdbcd9ccde87acddb4ec6f514 | "define"in window&&define("discourse/theme-3/initializers/theme- | 2019-02-25 01:26:58.228209 | 2023-08-18 20:50:41.049209 | | {"version":3,"sources":["discourse/initializers/theme-field-3-co
The content looked familiar, so I went into the Customize → Theme → My Theme → Common → Head, made a minor tweak and saved and I can see that one of the entries was updated and one of them remains old…
discourse=# select id, theme_field_id, digest, substring(content from 1 for 64) as content_64, created_at, updated_at, theme_id, substring(source_map from 1 for 64) as source_64 from javascript_caches where theme_field_id = 3;
id | theme_field_id | digest | content_64 | created_at | updated_at | theme_id | source_64
----+----------------+------------------------------------------+------------------------------------------------------------------+----------------------------+----------------------------+----------+------------------------------------------------------------------
2 | 3 | 7fd74ecf4448afccdbcd9ccde87acddb4ec6f514 | "define"in window&&define("discourse/theme-3/initializers/theme- | 2019-02-25 01:26:58.228209 | 2023-08-18 20:50:41.049209 | | {"version":3,"sources":["discourse/initializers/theme-field-3-co
1 | 3 | 7f4132b1f9ced1b90b8f8fc24812cc11e81fea8d | "define"in window&&define("discourse/theme-3/initializers/theme- | 2019-02-25 01:26:56.606537 | 2023-09-13 21:56:56.312263 | | {"version":3,"sources":["discourse/initializers/theme-field-3-co
(2 rows)
Again, I’m not sure what the implication of these duplicates are, if it’s safe to delete the ‘old’ one, or if there’s some other way to ‘rebuild’ the caches which would clean this up?