good story to deal with custom managers

[jerch]

Coming from #120 - we prolly want some sort of a setting/argument around computed fields to specify a certain manager to be used. This needs some thinking how to shape / where to place such a setting, as we currently only have an explicit API on field level, while managers act model-wide.

[jerch]

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: declare a Model.Meta variable to point to the manager to be used, downside - Meta overloads are kinda nasty in model inheritance
• investigate: can proxy models solve this issue on a higher abstraction level?

What should be covered by this:

• limit cf processing by filter condition on source models (eww, those are not necessarily CFMs!)
• limit cf processing by filter condition on target CFM
• needs some "escape hatch"/fallback to forcefully process all cf records

Hmm not sure yet, if it is worth to be implemented:

• introduces desync state for filtered out entries - Do we really want that? This complicates overall state handling a lot, as we would have to track that explicit desync state somehow and offer some way to resolve it at a later stage. Bad idea...
• gives only a small update time benefit by skipping entries, which will only pay off for very big tables under heavy/fast changes - Are there valid use cases for this? (Prolly yes, but big table + fast turning entities sounds very much like squeezing a cache problem into a db - not the best idea)

On the other hand, it would partially solve a current issue with cfs - a cf, that aggregates many datapoints into a final result gets always immediately updated from a single datapoint change. If there are multiple changes at different datapoints at once, this create a lot of nonsense interim updates, which cannot be avoided currently with the instance obj interface. While custom managers can partially solve this, it still might not be the best way to solve it.

Overall it boils down to the question, if we want to allow some sort of explicit interim desync state to stack up multiple updates into one final one.*

Still very unsure about this...

---

[*] So far this did not came up as a real issue. But a prolly better way to solve that might be some sort of a context, which allows to update db fields without triggering any cf updates immediately, instead doing it at the end in one mass action...