Replace `mark-category-fields-as-list` with a Liquibase migrations (#20405)

* Replace metabase.db.migrations/mark-category-fields-as-list with a Liquibase migration

* Fix stray comma

resources/migrations/000_migrations.yaml

@@ -9934,6 +9934,51 @@ databaseChangeLog:
               WHERE `key` = 'site-url'
                 AND value NOT LIKE 'http%';
 
+  #
+  # The following migration replaces metabase.db.migrations/mark-category-fields-as-list, added in 0.29.0
+  #
+  # Starting in version 0.29.0 we switched the way we decide which Fields should get FieldValues. Prior to 29, Fields
+  # would be marked as special type Category if they should have FieldValues. In 29+, the Category special type no
+  # longer has any meaning as far as the backend is concerned. Instead, we use the new `has_field_values` column to
+  # keep track of these things. Fields whose value for `has_field_values` is `list` is the equiavalent of the old
+  # meaning of the Category special type.
+  #
+  # Note that in 0.39.0 special type was renamed to semantic type
+  - changeSet:
+      id: v43.00-012
+      author: camsaul
+      comment: >-
+        Added 0.43.0. Set Field.has_field_values to 'list' if semantic_type derives from :type/Category.
+      preConditions:
+        - onFail: MARK_RAN
+        - sqlCheck:
+            expectedResult: 0
+            sql: >-
+              SELECT count(*)
+              FROM data_migrations
+              WHERE id = 'mark-category-fields-as-list';
+      changes:
+        - sql:
+            # This is a snapshot of all the descendants of `:type/Category` at the time this migration was written. We
+            # don't need to worry about new types being added in the future, since the purpose of this migration is
+            # only to update old columns.
+            sql: >-
+              UPDATE metabase_field
+              SET has_field_values = 'list'
+              WHERE has_field_values IS NULL
+                AND active = true
+                AND semantic_type IN (
+                  'type/Category',
+                  'type/City',
+                  'type/Company',
+                  'type/Country',
+                  'type/Name',
+                  'type/Product',
+                  'type/Source',
+                  'type/State',
+                  'type/Subscription',
+                  'type/Title'
+                );
 
 # >>>>>>>>>> DO NOT ADD NEW MIGRATIONS BELOW THIS LINE! ADD THEM ABOVE <<<<<<<<<<
 

src/metabase/db/data_migrations.clj

@@ -11,13 +11,11 @@
             [clojure.tools.logging :as log]
             [clojure.walk :as walk]
             [medley.core :as m]
-            [metabase.db.util :as mdb.u]
             [metabase.models.card :refer [Card]]
             [metabase.models.collection :as collection :refer [Collection]]
             [metabase.models.dashboard :refer [Dashboard]]
             [metabase.models.dashboard-card :refer [DashboardCard]]
             [metabase.models.database :refer [Database]]
-            [metabase.models.field :refer [Field]]
             [metabase.models.humanization :as humanization]
             [metabase.models.permissions :as perms :refer [Permissions]]
             [metabase.models.permissions-group :as perm-group :refer [PermissionsGroup]]
@@ -143,24 +141,6 @@
     ;; use `simple-delete!` because `Setting` doesn't have an `:id` column :(
     (db/simple-delete! Setting {:key "enable-advanced-humanization"})))
 
-;; Starting in version 0.29.0 we switched the way we decide which Fields should get FieldValues. Prior to 29, Fields
-;; would be marked as special type Category if they should have FieldValues. In 29+, the Category special type no
-;; longer has any meaning as far as the backend is concerned. Instead, we use the new `has_field_values` column to
-;; keep track of these things. Fields whose value for `has_field_values` is `list` is the equiavalent of the old
-;; meaning of the Category special type.
-;;
-;; Since the meanings of things has changed we'll want to make sure we mark all Category fields as `list` as well so
-;; their behavior doesn't suddenly change.
-
-;; Note that since v39 semantic_type became semantic_type. All of these migrations concern data from before this
-;; change. Therefore, the migration is set to `:catch? true` and the old name is used. If the column is semantic then
-;; the data shouldn't be bad.
-(defmigration ^{:author "camsaul", :added "0.29.0", :catch? true} mark-category-fields-as-list
-  (db/update-where! Field {:has_field_values nil
-                           :semantic_type     (mdb.u/isa :type/Category)
-                           :active           true}
-    :has_field_values "list"))
-
 ;; Before 0.30.0, we were storing the LDAP user's password in the `core_user` table (though it wasn't used).  This
 ;; migration clears those passwords and replaces them with a UUID. This is similar to a new account setup, or how we
 ;; disable passwords for Google authenticated users