-
-
Notifications
You must be signed in to change notification settings - Fork 1k
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
Serialize the panels #1826
base: serializable
Are you sure you want to change the base?
Serialize the panels #1826
Conversation
This matches the new naming defined in the store module and will make things eaiser to change moving forward. This will break anything using the store internally causing issues for third party packages.
The remainder of the work is to fix the individual panels' serialization errors.
This avoids needing to create an instance of a panel to get its panel ID.
c728270
to
14a5e0c
Compare
I think this is at a point where we can add some async tests to confirm that this approach will work or not. |
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.
Thanks!
- I like the change from store IDs to request IDs.
- It's nice that we no longer accept SQL strings from the client and execute them (even with signing)
I'm not totally sure, is this (somewhat) backwards compatible for third party panels? This wouldn't be an argument against it, just something to clarify.
While it doesn't break any documented APIs for the panel to function itself, this version is not backwards compatible since it loads the content for the panel from the store ( |
@matthiask I'm back to forcing everything that can't be serialized to JSON to a str. Otherwise we're trying to do it manually per panel which will involve a function that's likely going to do similar object and collection iteration as |
The alternative here is to inspect and iterate over every collection and object passed around. This avoids having to reinvent the wheel in that scenario.
Any instance attributes shouldn't be used because they can't be relied upon for historical purposes. Especially when it comes to the titles and nav titles.
This assumes we'll have some shared memory store for the cache hence the change to |
Why is that? |
This is a draft PR. I'm keeping my on-going work in this branch. I found that my efforts to close #1807 and #1808 quickly spiraled into a major refactor of core logic.
This currently handles the SQLPanel which required the following changes:
raw_params
entirely. We'll need to serialize the parameters every time now so we can't rely on the original paramsdjdt_query_id
which uniquely identifies each query. The SQL forms now reference this id and avoid passing SQL to be executed.In addition this also changed our design for
Panel
load_stats_from_store
- Generates aPanel
instance with the passed in data.Panel.panel_id
is now a class member to avoid needing to instantiate a panel to programatically get the panel id. With the new focus on fetching data for a specific panel given its ID, this became more of a need