Skip to content
Snippets Groups Projects
This project is mirrored from https://github.com/metabase/metabase. Pull mirroring updated .
  1. Jun 07, 2024
    • metabase-bot[bot]'s avatar
      Move database role to url parameters from connection properties on Snowflake (#43602) (#43835) · 55821acb
      metabase-bot[bot] authored
      
      * Move role to url parameters from connection properties
      
      * Fix test
      
      Co-authored-by: default avatarlbrdnk <lbrdnk@users.noreply.github.com>
    • metabase-bot[bot]'s avatar
    • John Swanson's avatar
      Fix remaining `tinyint` booleans in MySQL (#43296) (Backport #43296) (#43781) · 5eb26508
      John Swanson authored
      
      * Correct type for `report_card.dataset`
      
      This was missed in the original migration of boolean types to
      ${boolean.type} in MySQL/MariaDB, and then missed again by me when I
      migrated `collection_preview` over a week ago.
      
      * Change all boolean types to `bit(1)` in MySQL
      
      Liquibase changed their boolean type in MySQL from `bit(1)` to
      `tinyint(4)` in version 4.25.1. Our JDBC driver does not recognize these
      as booleans, so we needed to migrate them to `bit(1)`s.
      
      As discussed [here](#36964), we
      changed all existing `boolean` types that were in the
      `001_update_migrations.yml` but not the SQL initialization file.
      
      For new installations, this works: things in the SQL initialization file
      get created with the `bit(1)` type.
      
      However, for existing installations, there's a potential issue. Say I'm
      on v42 and am upgrading to v49. In v43, a new `boolean` was added.
      
      In this case, I'll get the `boolean` from the liquibase migration rather
      than from the SQL initialization file, and it need to be changed to a
      `bit(1)`.
      
      I installed Metabase v41 with MySQL, migrated the database, and then
      installed Metabase v49 and migrated again. I made a list of all the
      columns that had the type `tinyint`:
      
      ```
      mysql> SELECT TABLE_SCHEMA, TABLE_NAME, COLUMN_NAME, COLUMN_TYPE,        COLUMN_DEFAULT, IS_NULLABLE FROM INFORMATION_SCHEMA.COLUMNS WHERE COLUMN_TYPE = 'tinyint' AND TABLE_SCHEMA='metabase_test';
      +---------------+------------------------------+-------------------+-------------+----------------+-------------+
      | TABLE_SCHEMA  | TABLE_NAME                   | COLUMN_NAME       | COLUMN_TYPE | COLUMN_DEFAULT | IS_NULLABLE |
      +---------------+------------------------------+-------------------+-------------+----------------+-------------+
      | metabase_test | core_user                    | is_datasetnewb    | tinyint     | 1              | NO          |
      | metabase_test | metabase_field               | database_required | tinyint     | 0              | NO          |
      | metabase_test | metabase_fieldvalues         | has_more_values   | tinyint     | 0              | YES         |
      | metabase_test | permissions_group_membership | is_group_manager  | tinyint     | 0              | NO          |
      | metabase_test | persisted_info               | active            | tinyint     | 0              | NO          |
      | metabase_test | report_card                  | dataset           | tinyint     | 0              | NO          |
      | metabase_test | timeline                     | archived          | tinyint     | 0              | NO          |
      | metabase_test | timeline                     | default           | tinyint     | 0              | NO          |
      | metabase_test | timeline_event               | archived          | tinyint     | 0              | NO          |
      | metabase_test | timeline_event               | time_matters      | tinyint     | NULL           | NO          |
      +---------------+------------------------------+-------------------+-------------+----------------+-------------+
      10 rows in set (0.01 sec)
      ```
      
      Then wrote migrations. For each column, we:
      
      - turn it into a `bit(1)`,
      
      - re-set the previously existing default value, and
      
      - re-add the NOT NULL constraint, if applicable.
      
      * Change author and add missing `dbms`
      
      ---------
      
      Co-authored-by: default avatarSakuragiYoshimasa <ysrhsp@outlook.com>
  2. Jun 06, 2024
  3. Jun 05, 2024
  4. Jun 04, 2024
  5. May 31, 2024
  6. May 30, 2024
    • lbrdnk's avatar
      [Manual backport] Backfill :effective-type for coerced fields (#43144) (#43358) · e9396b21
      lbrdnk authored
      * [Manual backport] Backfill :effective-type for coerced fields (#43144)
      
      * Remove bulk-metadata "pre-warm" call
      
      bulk-metadata implementation for metadata provider in use
      is not present on this branch. Hence the pre-warm call was
      removed. Passing of no-lazyness-test hints that should be ok.
      
      * Update test
      
      query reqires keywordized form on 49
      
      * Fix missing every-pred
  7. May 28, 2024
  8. May 27, 2024
  9. May 23, 2024
  10. May 21, 2024
    • John Swanson's avatar
      Fix `report_card.collection_preview` in v49 (#42921) · bab351f5
      John Swanson authored
      This is a bit painful. I merged this change, but realized we need to
      backport the fix to v49. However:
      
      - we don't want to have two versions of the migration (one with a v49
      id, one with a v50 id) because then if someone upgrades to 50, then
      downgrades to 49, the `rollback` will run and change the type back,
      leading to a bug.
      
      - we don't want to push a v51 changeSet ID to v49 or v50, because we
      give the user a helpful notice when their database needs a downgrade.
      We do this by checking for the latest *executed* migration in the
      database and comparing it to the latest migration that Liquibase knows
      about, and making sure the executed isn't bigger than the known (e.g.
      you can't have executed a v51 migration if it isn't in the local
      migration yaml). That would all work fine, except that then we want to
      tell you how to downgrade your database, and we use the latest-executed
      version for that. So if, for example, someone upgraded from 48 to 49 and
      got a v51 changeset, then downgraded back to 48, they would get an error
      telling them to run the *v51* jar to roll back their DB.
      
      In this case though, I think it's fine to just move the migration around
      to v49, then we can backport it to 49 and 50.
  11. May 20, 2024
  12. May 17, 2024
  13. May 16, 2024
  14. May 15, 2024
  15. May 14, 2024
  16. May 13, 2024
  17. May 10, 2024
Loading