Panel data stored in memory for subsequent requests

[kkaehler]

It looks like all of the data is stored in process memory here, and then fetched in subsequent requests from the browser. This works fine locally but obviously breaks in a multi-process environment. While obviously this shouldn't be used in production, we would love to be able to run the toolbar on our staging environment to see realistic query plans more easily.

What if we moved the _store into a singleton class that determined which type of storage to use from a setting? We could default to an OrderedDict but allow custom overrides to use any storage type. I am thinking that we would use django cache so I could commit that storage if you would like.

[aaugustin]

I'm afraid the data isn't pickleable in general, which means you can't put it in a Django cache easily.

[kkaehler]

Ahh, that is too bad. Would it just be more work to make the panels serializable or do features depend on having the exact same python instances?

[aaugustin]

It's essentially outside of the toolbar's control.

The template panel, which is arguably one of the most useful panels, keeps track of the template rendering context, where developers may put arbitrary Python values. It would be annoying if the toolbar failed randomly depending on what a particular view puts in the context...

Generally speaking, being a debug tool, the toolbar has to be extremely resilient to whatever a developer may throw at it and it cannot make assumptions about things it handles.