Skip to content
Snippets Groups Projects
This project is mirrored from https://github.com/metabase/metabase. Pull mirroring updated .
  1. Apr 26, 2024
  2. Apr 25, 2024
  3. Apr 24, 2024
  4. Apr 23, 2024
  5. Apr 22, 2024
  6. Apr 19, 2024
  7. Apr 18, 2024
  8. Apr 17, 2024
  9. Apr 16, 2024
    • Denis Berezin's avatar
      Embedding SDK - Fix table header styles calculation (#41449) · caac0cb6
      Denis Berezin authored
      * Fix table styles calculation
      
      * Review fixes
      
      * Fix unit tests
      Unverified
      caac0cb6
    • Braden Shepherdson's avatar
      Use cached Malli validators/explainers; make `:fn` schemas cacheable (#39947) · 8c2c556a
      Braden Shepherdson authored
      This improves our Malli performance substantially! Many of our code paths were calling vanilla `malli.core/validate` or `malli.core/explain`; these redo the (possibly expensive) compilation of the schema into a validator or explainer for every call.
      
      We should use the caching versions in `metabase.util.malli.registry` everywhere, and our runtime performance will be much improved.
      
      However when I started using these cached versions, I found that the memory use was growing out of control. Eventually I tracked this down to `:fn` schemas. Functions are only comparable by pointer equality, so they make poor cache keys. `(fn ...)` or `comp` calls in a schema on a `mu/defn` function **get re-created for every call of the `mu/defn`'d function**! That's a big time sink recompiling the schemas if we're *not* caching, and a huge memory sink if we *are* caching!
      
      This PR pulls every such schema I could find out into a `def` so it uses the same closure and is cacheable. I'd like to automate that in some part of the Malli pipeline, or maybe a linter rule, but I haven't found a good way to do it yet.
      
      Part of #39946.
      Unverified
      8c2c556a
    • Nemanja Glumac's avatar
      Re-wire the `Users` entity to use RTK Query under the hood (#41312) · 093308d2
      Nemanja Glumac authored
      * Define the types for the `create` user request
      
      * First draft for the create user API using RTK Query
      
      * Export RTK user API
      
      * Define explicit `create` api for the user entity
      
      * Define `updatePassword` mutation
      
      * Wire users entity `resetPasswordManual` to use RTK under the hood
      
      * Use `updatePassword` mutation
      
      * Wire users list calls
      
      * Remove unused `update_password` from services
      
      * Fix the dispatch used to list users
      
      * Dispatch the action type and the payload
      
      * Wire `deactivateUser` to work with RTK
      
      * Wire `reactivateUser` to work with RTK
      
      * Delete unused entries from `UserApi`
      
      * Convert the reducer to use `switch` statement
      
      * Remove unused user `send_invite` endpoint from FE
      
      * Wire `resetPasswordEmail` in users entity to work with RTK
      
      * Provide cache invalidation for the `userApi`
      
      * Add `provideUserListTags` helper
      
      * Pass `email` as a sole argument
      
      * Throw on `get` a user
      
      This endpoint hasn't been used in a long itme.
      Removed in https://github.com/metabase/metabase/pull/41334/files#diff-241e0afa11f03a0942eb322aa47695e58496379b0b6d42e6e59ecf6a20fe623cL448
      
      * Use RTK Query to `updateUser`
      
      * Fix wrong syntax
      
      * Use RTK Query to `getUser`
      
      It was used by `.load` and `fetch` after all.
      
      * Export `useUpdateUserMutation`
      
      * Refactor `getRecipientsList`
      
      * Fix response type for the `getUser`
      
      * Pass user id as a sole argument instead of in an object
      
      * Fix users entity `get` method
      
      * Fix the user update password form
      
      * Fix unit tests
      
      * Fix deactivate and reactivate query invocations
      
      See e949812.
      
      * Adjust types according to the feedback
      
      * Order utils alphabetically
      
      * Throw on `delete`
      
      * Revert "Fix unit tests"
      
      This reverts commit 2c329e836427010ad08bfd0511eb1a9df4ba95d6.
      
      * Fix FE unit test mocks
      
      * Rename imports to use plural for consistency
      
      * Fix one last remaining FE unit test
      Unverified
      093308d2
  10. Apr 15, 2024
  11. Apr 12, 2024
  12. Apr 11, 2024
  13. Apr 10, 2024
    • dpsutton's avatar
      Fix #39138 again (#40936) · b1e83541
      dpsutton authored
      * Fix #39138 again
      
      Fixes #40934
      
      Got unfixed somehow in #40578. seems like some file renames caught it off guard
      
      But the long and short is that its possible for a persisted model to end
      up in the state "refreshing" (possible an instance restart during
      refreshing). The refreshing job doesn't look for these so they become
      effectively invisible.
      
      Since the job to refresh them will only run one at a time cluster wide,
      any jobs that are in the "refreshing" state when the refresher begins to
      refresh are necessarilly stuck (no one else could currently be
      refreshing them). So we can just add them to the queue of models to
      refresh.
      
      ```clojure
      (jobs/defjob ^{org.quartz.DisallowConcurrentExecution true ;; <----
                     :doc "Refresh persisted tables job"}
        PersistenceRefresh [job-context]
        (refresh-job-fn! job-context))
      ```
      
      * Ensure ee/oss pathways are taken in tests
      
      Annoying little footgun here. CI does not run with an ee token, so in
      order to ensure that test pathway goes through ee version of a
      defenterprise we _must_ use the `mt/with-premium-features
      {:cache-granular-controls}`,  but we also want to ensure that it goes
      through the oss version.
      
      So two options, a `doseq` on both features (empty set and the feature
      that triggers this). But want a test in the enterprise folder as well to
      ensure.
      
      The real trickiness comes from running tests at a repl and CLI. My REPL
      always has an ee token in it. My command line always lacks that as
      well. So want to be explicit about the token features in effect at test
      time.
      
      That's why I'm essentially duplicating tests (ee in ee folder, oss in
      regular pathway)
      Unverified
      b1e83541
Loading