better support for multi-table inheritance

[olivierdalang]

Hey !

Still using&loving this package a lot. Thanks so much for sharing your work :-)

In a current project, we use multi-table inheritance quite extensively to model a somewhat complex business domain (with django-polymorphic). We aren't too concerned about performance (it's an internal tool with relatively few objects and few users).

The docs make it clear that rules aren't expanded to subclasses, and admits it's not so intuitive:

Why do I have to create those counter-intuitive rules?

The resolver does not expand on multi table inheritance automatically. Furthermore it might not be wanted in all circumstances, that parent or derived models trigger updates on other ends. Thus it has to be set explicitly.

Would it be an option to make it possible to expand the dependencies in cases where it is wanted ?

I'm thing of a new argument on the @computed decorator, or maybe even better per dependency (maybe by prefixing or suffixing the dotted relation path with + or * or something ?).

I'm not sure how easy it would be to do that in client code as I guess the related models are not necessarily already loaded at the time of the computed_fields declaration. For now I'm just listing all sub-tables, and it works, but it makes it easy to forget to update the computed_field definition when adding a new subclass.

Example

    depends=[
        ('animals+', ['alive']),
    ]

Cheers,

Olivier

[jerch]

Hey @olivierdalang

Yes that can be done, but the way to declare the intention and resolve it correctly will get cumbersome. Will have to think about it for some time, but already I think your annotation idea goes into the right direction.

The main hassle I see upcoming here is for deeper nested MT models and resolving those correctly automatically, e.g. depends=[('a.b+.c', ['f1', 'f2'])]. This is tricky to filter the correct fields on the right side down (here c is right of b).