Add option to automatically follow Django relations and query for them. about django-dump-die HOT 2 OPEN

This very much could get very expensive very fast. 100% agree that IF we implement this, we would need settings to limit how deep/expensive it can get.

Also, for clarification, when would this be called? Is it some kind of additional JavaScript that dynamically calls relations as the user clicks elements on the DD page? Is it called during initial model/query processing, as part of initial DD-page middleware computations? Some in between?

I feel like these details should be determined BEFORE we would try to implement such logic. So it's very clear what our goal is before we start work on it.

from django-dump-die.

For clarification, this original issue post is specifically regarding M2M relations, with the select_related and prefetch_related options. It seems they (maybe?) don't output, or don't output in useful ways by default? Need to verify exactly what the output is. Either way, if we implement this, we probably want to also double check output of standard FK/one-to-one relations, and verify they output in DD how we want. Just so all model relations are handled consistently and how we want.

Anyways, after discussing this further, it sounds like we're leaning on two options:

1. Easier Option - Add another optional kwarg to the dd functions. When provided, will first verify that the provided object is a Django query, and then do some additional logic to ensure nicer output, using the kwarg values.

2. More Complicated Option - Implement with some sort of JS/AJAX calls. So the relation will display in the original DD output, but the actual data will not persist to the page until the user clicks to expand the given attribute. At which point some sort of JS will trigger to pull whatever the value is, and then render the result to the page.

Option 1 is much easier to implement, but much less dynamic. In that it requires the user to know what relations they care about in advance. If they don't know, then they need to load the initial dd page, figure out what they want to see, then modify the initial call and reload the dd page for the new data.

Option 2 will probably have lower upfront cost for page rendering, and is very dynamic in that the user can have no idea what they're expecting to see, and yet they can still get to the data they ultimately want. But it will take significantly more work to implement, and we're not sure we want to invest that amount of extra time into this package.

These two options are not mutually exclusive and we can potentially do both if we want.

from django-dump-die.