Serialize the panels #1826
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.
tim-schilling
force-pushed
the
serialize-panels
branch
from
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.
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 |
|
from the above changes in consideration in consideration I was able able to run example with async calls 
however I believe this async example would also work without serialised panels. |
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_paramsentirely. We'll need to serialize the parameters every time now so we can't rely on the original paramsdjdt_query_idwhich 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
Panelload_stats_from_store- Generates aPanelinstance with the passed in data.Panel.panel_idis 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