Replies: 1 comment
-
|
Update: speed up wasn't consistent in the app I'm using, I think a better mechanism than re-sorting everything at the end, than what I used in the gist might help. |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
-
select_related, fails when you have different foreign keys on different parent classes.
I made a workaround, where the query is split up by type id, then for each of those select_related can be called -
https://gist.github.com/stuaxo/1e5f272d84e68eceaddafa0c7f9d37ae
For the data I'm using, I saw about a 3x speed up.
I wonder what the sane API for a django polymorphic select_related would look like ?
For the code, above we have a special field, "copyable_fields", and I choose things, based off that... that's probable not acceptable here, I guess if it was it might look like this (using the field name from my project above)
.polymorphic_select_related(fields_list="copyable_fields")A slightly cumbersome alternative might be to pass in the list of fields to select_related, for each type
.polymorphic_select_related({Class1: ["field1", "field2"], Class2: ["field2", "field3"]})This second one may not be as bad as it seems, as it could probably be done dynamically, I could even reproduce what I'm doing on my current project:
.polymorphic_select_related(model: model.copyable_fields for model in TrackedModel.__subclassess__())Any other ideas ?
Beta Was this translation helpful? Give feedback.
All reactions