-
Notifications
You must be signed in to change notification settings - Fork 39
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
Include only required fields in data #195
base: master
Are you sure you want to change the base?
Conversation
Codecov Report
@@ Coverage Diff @@
## master #195 +/- ##
=========================================
+ Coverage 84.61% 85.32% +0.7%
=========================================
Files 12 12
Lines 416 436 +20
=========================================
+ Hits 352 372 +20
Misses 64 64
Continue to review full report at Codecov.
|
Yeah, this is a good idea! Does it handle nested specs, and fields that appear in transforms and things like that? Essentially there are many places in a spec where a field name can appear, and I think we need to find all of them, right? |
The code in this PR accumulates all values in the dicts with the key named Lines 94 to 103 in 35bad05
except for I think this covers transforms. Is there other ways that fields can be referred to in vega-lite spec? |
Hm, filter transforms for example can reference columns in their filter expression? Lookup can have something called |
I wonder whether there is some function in vega that one can pass a spec to and that spits out which columns are actually needed... |
Oh, I wasn't aware of filtering expression. That's pretty cool but it makes this approach super difficult... |
Maybe do this only when there is no |
I've asked on the vega-dev channel whether there is some function that might tell us all the columns that are needed, if that exists it would be an easy solution :) And yes, if not, only doing this when there are no |
Thanks for asking this to the vega team! |
I'm pretty optimistic that they might have something like that, after all they also support a scenario where you can have a SQL backend, and they ship a SQL query back to you that filters exactly the data they need, and I would think that they also need a list of columns they need for that... |
This PR makes the following snippet work
Before this PR, it hangs as described in davidanthoff/Electron.jl#37. While this is not the direct solution for davidanthoff/Electron.jl#37, I think this still is a nice feature to have as this can drastically reduce generated JSON sometimes. The only downside may be that you can't open the plot in Vega Editor and use different fields on the fly. I think we can add global and per-plot configuration for this if that's needed.