-
Notifications
You must be signed in to change notification settings - Fork 4.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Various readability improvements around based_on_upload #38507
Conversation
1542cff
to
af9b0e5
Compare
@@ -763,5 +759,6 @@ | |||
- uploads are enabled | |||
Otherwise based_on_upload is nil." | |||
[cards] | |||
(let [models-by-id (m/index-by :id (model-hydrate-based-on-upload (filter :dataset cards)))] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This naming threw me, given the long discussion we had against this style, and instead sticking to Tellman style 😆 - did I misunderstand where we ended up?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ha, maybe this is a different scenario where x-by-y
adds to readability. models-by-id
at least implies that it is a map of a model ID to a model (maybe it should rather be model-by-id
), as opposed to card ID to a model. Because the name reminds me of how it was created: either m/index-by
or clojure.core/group-by
. But I think id->model
is also fine.
The use of card->model
here is a little surprising for me though. The english description of this function based on its behaviour would be "Returns a hydrated model if a card is a model". Yet to me the name card->model
implies that there is one model per card. Not an opinion I hold strongly though
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmm - surely it's still implicit that the id corresponds to the model? Otherwise I'd imagine it being called card-id->model
. I still agree that -by-
is pretty natural, but I do prefer consistency.
To understand your issue with the second mapping, it sounds like you're unhappy with a few aspects of the name:
- that we are mapping to the "same" resource, not some related one (e.g. a source)
- the mapping will be used for non-model cards too, and it will return nil in that case.
- we are mapping between a "raw" and "hydrated" value
Those are all good points, but I'm not sure the old code was any clearer in this regard?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm only unhappy with this
the mapping will be used for non-model cards too, and it will return nil in that case.
the name card->model
doesn't imply that it returns nil
for cards that aren't models.
model-by-id
does.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How about card->maybe-model
then?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I like the rule. I don't mind that much with card->maybe-model
. Apologies for splitting hairs again on naming, maybe why I like inlining things is because I'm so critical of names
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Don't miss naming day in the gym! In the mean time I'll be doing some "reading code that is more dense than I'm used to" reps.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
oh you should be aware of another reason I don't like names: I have an aversion to newlines because I work without an external monitor and hate scrolling :D
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is it at least 16"? 😆
I feel so blind when I'm just on one small screen for pairing, for sure following references is less painful when they open in a split pane.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, 16. Before metabase it was even smaller.
|
src/metabase/upload.clj
Outdated
(map #(m/assoc-some % :based_on_upload (based-on-upload %)) | ||
models))) | ||
query? (fn [model] (= "query" (name (:query_type model "query")))) | ||
uploadable? (comp (uploadable-table-ids table-ids) :table_id)] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This function takes a model as an arg, yet doesn't determine whether a model is "uploadable" or not. A more appropriate name would be has-uploadable-table-id?
but at that point you might as well inline it
uploadable? (comp (uploadable-table-ids table-ids) :table_id)] | |
has-uploadable-table-id? (comp (uploadable-table-ids table-ids) :table_id)] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How about uploadable-id?
I have a pretty strong aversion to mixing abstraction levels in the (when (and x y z) ...)
cluster, a capital offense in my fashion guide.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Or uploadable-table
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
uploadable-id?
suffers from the same problem because the "id" in the name is ambiguous. has-uploadable-table?
is pretty clear though.
For myself I don't have such a strong aversion to mixing abstration levels. This is all in the name of readability and introducing extra names comes at a cost because they can be misleading and will make your eyes jump around if you have to understand them.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That has-
hurts me - especially at it forces a re-indent on the let bindings, but agree that without it there's a bit more ambiguity though - uploadable-table?
could make it sound like there is "exactly one" uploadable tables, when really its "at least one". We rely on the lack of joins to make it exact, and that call is more expensive so it makes sense to keep it later in the and
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah. To understand what the table in uploadable-table?
means you almost need to know that it's referring to the table from the source-table
from the first stage of the query. It's unfortunately complicated
The tests are failing for some reason I can't deduce from inspection |
I also can't grok it. Hoping it's a transient CI issue, will investigate if it still isn't passing this afternoon. |
It doesn't seem transient CI related, it's failing on the exact functions you're modifying |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM, I fixed the "bug" causing the test failures. It was because the dataset_query
can be {}
in tests that don't test the query processor, so no-joins?
ran into a NPE because MLv2 expects valid queries
06ab928
to
d293352
Compare
@crisptrutski Did you forget to add a milestone to the issue for this PR? When and where should I add a milestone? |
* serialization: snowplow events for export/import (#38487) * Dashboard sections (#38463) * Add `ADD_MANY_CARDS_TO_DASH` action * Reuse `NewDashCardOpts` type * Extract `DashboardCardLayoutAttrs` type * Add basic `DashCardPlaceholder` viz * Add section layouts * Add `addSectionToDashboard` redux action * Add `SectionLayoutPreview` component * Add "Add section" button to dashboard header * Allow placeholder cards in `replaceCard` * Make heading cards transparent by default * Fix layout fn usage * Update mapping UI for placeholder cards * Fix tooltips position * Add `createMockPlaceholderDashboardCard` * Test `replaceCard` works with placeholder cards * Extract common `setup` from cards actions tests * Add `createMockDashboardTab` * Add unit tests for `addSectionToDashboard` * Placeholder cards work for emails/pulses Dashboards with placeholder cards now properly email rather than throwing an exception. Placeholder cards themselves are not sent as part of the email as they are empty. * Merge remote-tracking branch 'origin/38209-dashboard-sections' into 38209-dashboard-sections * Adding tests for placeholder cards and empty dashboards * Fix parameter mappings UI * Update section card sizes * Clean up * Add button label * Add E2E test * Revert * Reorder * Fix menu position * Assert placeholder card doesn't have a button * Fix menu tooltips * Fixing unit tests * Removed dangling code * Fixing unit tests * Remove virtual cards handling from `replaceCard` --------- Co-authored-by: Mark Bastian <markbastian@gmail.com> * bump toucan2 dependency (#38527) pulling in camsaul/toucan2#162 to fix #38516 * [QC] Remove `setDatabase` and `setDatabaseID` methods (#38550) * Remove `setDatabaseID` method from the `StructuredQuery` prototype * Remove `setDatabase` method from both Native and Structured queries * Fix time-interval against expressions (#38488) * Fix time-interval against expressions When simplifying time-interval filters, we forgot to place a temporal-unit on expressions, which meant that the date-trunc used by quarters had to match the date exactly rather than being in the interval range. * Update optimize temporal filters for expressions There is a dependency with this middleware and mongo. Without optimization mongo cannot compare the bucketed timestamps because AFAICT mongo 4 doesn't have date truncation so we do so in clojure for the compared literal but cannot do the lhs field/expression. * Avoid unnecessary re-renderings in because of getQuestions selector (#38548) * Avoid unnecessary re-renderings in DashboardSharingEmbeddingModal * Add deep equal selector * drop underscore * load analytics only when changed using a checksum (#38280) * load analytics only when changed using a checksum - over audit deserialization files * update docstrings * fix testing wording * [QC] Remove unused methods from the `StructuredQuery` prototype (#38551) * Meet embedders - minimal version (#38520) * refactor: prepare SettingsPage to have conditionally rendered steps (#38201) * refactor: prepare SettingsPage to have conditionally rendered steps * fix tests missing props * Usage reason question (#38267) * Invactive -> Inactive * add question * fix e2e test * small refactor * Update frontend/src/metabase/setup/components/UsageQuestionStep/UsageQuestionStep.tsx Co-authored-by: Mahatthana (Kelvin) Nomsawadi <me@bboykelvin.dev> --------- Co-authored-by: Mahatthana (Kelvin) Nomsawadi <me@bboykelvin.dev> * Hide "Add your data" step for people interested in embedding (#38390) * hide 'Add your data' step when user is interested in embedding * add other test cases * refactor: create selector * address pr feedback * adds minimal embed focused homepage (#38402) * very minimal homepage * fixed text color * minimal e2e + actual logic that i forgot lol * refactor the list to not have the numbers in the content * rename util functions * use button to have cursor when hovering + accessibility * refactor: move the waitFor inside the submit step * fix: make sure state is clean on multiple installs in a row * test: check that the homepage persists reload + removed typos * rename s to state * moved util functions up to home/utils.ts * adds key to avoid react warning * refactor and tests for [meet embedders] (#38465) * test: check all numbered steps during the setup flow * refactor: introduce getSteps and start using the step name instead of a number to identify steps * refactor: remove map of the steps, use step names directly * refactor: getNextStep * include 'hidden' steps in getSteps so that it won't mess up with analytics * fix after rebase issue * use full name instead of s, s -> step * analytics for meet-embedders (#38521) * refactor: extract schema version and onboarding version into constants * remove old ga events * trackUsageReasonSelected * update trackStepSeen to send the correct index * copy old schema for better diff * adds new snowplow event for usage_reason step * schema and e2e update for usage_reason_selected * adds utm tag to the link in the minimal embed homepage --------- Co-authored-by: Mahatthana (Kelvin) Nomsawadi <me@bboykelvin.dev> * Improve look of models in Browse data (#38518) Co-authored-by: Kyle Doherty <5248953+kdoh@users.noreply.github.com> Co-authored-by: Luiz Arakaki <luiz.arakaki@metabase.com> * Fix card query endpoint usage on dashboards (#38547) * Don't reload dashcards in edit mode * Update and unskip repro * Extend "duplicate tab" e2e test * Fix implicit request body schema when fetching dashcard data * Disable dashcard data refetching in edit mode * Revert `Dashboard` useEffect changes * Fix tests * Update default sizes for new dash width (#38450) * Migration adding 'width' to Dashboards 3 migrations: - 1st adding the width column with default value of 'fixed' - 2nd updating all existing dashboards to have width 'full', which corresponds to what the current behaviour is (will be the 'old' behaviour after the fixed-width project lands). - The rolloback here is necessary but we don't care what happens as the column will be dropped immediately in the next rollback anyway - 3rd sets the notNullableConstraint. DefaultNull is 'full' here, just in case there's an existing dashboard whose width value is not yet set from the 1st migration. Don't know how that could happen, but its here in case * Dashboard PUT api endpoint accepts width changes and updates appdb update-dashboard function now is aware of the :width key so those changes can end up in the transaction. Also added a width test that asserts that the value's default is "fixed", it can be changed, eg. to "full", but cannot be changed to other values. * Add width to revision tests * Fix dashboard revision tests. :width key is now needed in some revision tests. As well we need a string communicating that the :width setting has changed from 'full' to 'fixed' or vice-versa. * Fix comments/remarks in migration to be accurate * Attempt to fix default not working mysql/mariadb * Set default in dashboard model Signed-off-by: Adam James <adam.vermeer2@gmail.com> * Revert default :width 'fixed' value. * Explicitly add default value 'fixed' for MySQL/MariaDB * dashboard fixed width FE implementation * adjust popover shadow styling as the popover was blending in with the header * adjust extra button popover offset * add E2E to validate behavior * add fixed width container to public dashboards * fix public embedding not respecting dashboard width setting * add test for public dashboards * Fix embed test failures * add fixed width to x-ray dashboards * reduce code duplication * move FixedWidthContainer into DashboardGridConnected - We get the fixed-width w/o code duplication across AutomaticDashboardApp, PublicDashboard, and Dashboard * update E2E tests to reflect actual intended behavior * fix type errors * tweak default width of cards to accomodate fixed width * adjust tooltip button after merging changes from master * fix bar chart test failure * fix dashboard filters date test failure - new ellipsis button in dashboard edit mode broke the test * adjust test for new fixed width dashboards * adjust test for new fixed width dashboards * adjust test for new fixed width dashboards * bump funnel default width * adjust test for new fixed width dashboards * Fix double overlay for LineAreaBarChart dash-cards - No longer has an overlay that persists from editing mode to viewing mode - Adjust click-behavior tests to account for new grid-width. Old test relied on a dashcard being taller than they will now default to being. i.e. Move the chosen point/row to down an index. * Merge FixedWidthContainer with dashboard grid div * supress brush events while editing timeseries line charts on dashboard * fix failing test - test failed because I did not update this assertion based on previous changes * fix broken link input in editing mode * fix pointer events issue on text cards in edit mode * update tests for new dash-card default sizes * update tabs card moving test because of new default card sizes --------- Signed-off-by: Adam James <adam.vermeer2@gmail.com> Co-authored-by: Adam James <adam.vermeer2@gmail.com> Co-authored-by: adam-james <21064735+adam-james-v@users.noreply.github.com> Co-authored-by: Jesse Devaney <22608765+JesseSDevaney@users.noreply.github.com> Co-authored-by: Aleksandr Lesnenko <alxnddr@gmail.com> * add section icon and use in dashboard edit mode (#38575) * [MLv2] Use the provided `column-ref` for drills (#38047) There are cases where the ref as provided is not the same as what a fresh `(lib.ref/ref column)` would give. This seems mostly to affect models, where the metadata leaks some of the underlying details like joins. Fixes #38034. * Disable redshift support for uploads (#38583) * Disable table-privileges feature for MySQL (#38552) * Various readability improvements around based_on_upload (#38507) Co-authored-by: Callum Herries <calherries@gmail.com> * Remove flaky timeout in DelayGroup test (#38593) * Use greater than to assert timeout has elapsed * Use fake timers to test delay group * Don't instrument any namespaces for mu.fn/fn in production (#38482) * Remove handling MySQL <8 in table privileges test (#38546) * Update devcontainer Dockerile (#38598) * Embedding + required params (#38395) * fix linting after merge --------- Signed-off-by: Adam James <adam.vermeer2@gmail.com> Co-authored-by: Alexander Solovyov <alexander@solovyov.net> Co-authored-by: Anton Kulyk <kuliks.anton@gmail.com> Co-authored-by: Mark Bastian <markbastian@gmail.com> Co-authored-by: John Swanson <john.swanson@metabase.com> Co-authored-by: Nemanja Glumac <31325167+nemanjaglumac@users.noreply.github.com> Co-authored-by: Case Nelson <case@metabase.com> Co-authored-by: Uladzimir Havenchyk <125459446+uladzimirdev@users.noreply.github.com> Co-authored-by: bryan <bryan.maass@gmail.com> Co-authored-by: Mahatthana (Kelvin) Nomsawadi <me@bboykelvin.dev> Co-authored-by: Raphael Krut-Landau <raphael.kl@gmail.com> Co-authored-by: Kyle Doherty <5248953+kdoh@users.noreply.github.com> Co-authored-by: Luiz Arakaki <luiz.arakaki@metabase.com> Co-authored-by: Adam James <adam.vermeer2@gmail.com> Co-authored-by: adam-james <21064735+adam-james-v@users.noreply.github.com> Co-authored-by: Jesse Devaney <22608765+JesseSDevaney@users.noreply.github.com> Co-authored-by: Aleksandr Lesnenko <alxnddr@gmail.com> Co-authored-by: Braden Shepherdson <braden@metabase.com> Co-authored-by: Cal Herries <39073188+calherries@users.noreply.github.com> Co-authored-by: Chris Truter <crisptrutski@users.noreply.github.com> Co-authored-by: Callum Herries <calherries@gmail.com> Co-authored-by: Romeo Van Snick <romeo@romeovansnick.be> Co-authored-by: Thomas Schmidt <somtom91@gmail.com> Co-authored-by: Oleg Gromov <mail@oleggromov.com>
Description
A bunch of cosmetic feedback that missed the boat for #38322