jerch
jerch
For ref (dont like yet, where this leads) - quick&dirty test to get a hold of the related manager creation: ```python def _patch_fks(self) -> None: from django.utils.functional import cached_property from...
Some thoughts around custom cf managers... Early ideas how to shape this: - most simple and straight forward: hardcode a manager name, if found use this one - more versatile:...
Not directly, but you can create a dependent datetime field, that updates from changes on `comp`, something like this (untested): ```python class SomeModel(ComputedFieldsModel): fieldA = ... @computed(..., depends=[('self', ['fieldA'])]) def...
Right, thats not as easy as it sounds - currently the update resolver give no guarantees not to update a field in question. It resorts to "if in doubt -...
Thinking again about the issue the ideas above are not ideal for these reasons: - the double save approach will create havoc, if `comp_last_changed` is part of a `depends` entry...
@sbatdkio Hmm, it works with your provided info here. Does that other file, where `Action_Model` is defined, reside in a different django app? This pretty much looks like a model...
This is also linked to the issue, that we currently dont have any measures in place to enforce dependency strictness between `depends` and the function. Also see https://github.com/netzkolchose/django-computedfields/issues/135#issuecomment-1787104107.
There is another rather big optimization possible, if the original queryset contains the full table (`all()` without any filters) - here the WHERE IN filtering is very expensive for the...
Follow-up for above: The big speedup is still preserved, even if we keep the inner WHERE IN clause: ```sql SELECT * FROM "exampleapp_foo" WHERE "exampleapp_foo"."id" IN ( SELECT "exampleapp_bar"."foo_id" FROM...
Indeed, the transformed query performs slightly worse than the original with DISTINCT ON applied, if we add 100k foos linking to no bars/bazs: - original (current resolver) ```plain Planning Time:...