You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Background
The foreign key from TileModel -> NodeGroup was removed in v8 (under development) to support graph versioning, specifically so that graphs could migrate away to new versions while leaving tile data behind.
A property was added to add compatibility with .nodegroup calls, but unlike a Django model field which caches when you access it, or lets you select_related() to avoid the query in the first place, in Lingo we're seeing avoidable queries on every access.
Proposal
One of the goodies in Django 5.2 is that an API for expressing joins without foreign keys was made more public. See the section on ForeignObject. It's newly documented but has been stable for many versions.
I have a little proof of concept that lets us restore the prior functionality for things like:
Background
The foreign key from TileModel -> NodeGroup was removed in v8 (under development) to support graph versioning, specifically so that graphs could migrate away to new versions while leaving tile data behind.
A property was added to add compatibility with
.nodegroup
calls, but unlike a Django model field which caches when you access it, or lets youselect_related()
to avoid the query in the first place, in Lingo we're seeing avoidable queries on every access.See discussion.
Proposal
One of the goodies in Django 5.2 is that an API for expressing joins without foreign keys was made more public. See the section on ForeignObject. It's newly documented but has been stable for many versions.
I have a little proof of concept that lets us restore the prior functionality for things like:
etc. I can PR it so we can take a decision about it. The performance is one aspect and then there's avoiding a breaking change if we can.
This will also help with writing arches applications compatible with both 7.6 and 8.0.
cc/ @chrabyrd @chiatt
The text was updated successfully, but these errors were encountered: