Open scnerd opened 4 years ago
I could see some benefit for a decorator, but the underlying mechanism will still probably require model inheritance. Would this problem be solved by providing a NaturalKeyMixin
class instead?
class NaturalKeyMixin:
objects = NaturalKeyModelManager()
@classmethod
def get_natural_key_info(cls):
# ...
# ...
class NaturalKeyModel(NaturalKeyMixin, models.Model):
class Meta:
abstract = True
Can you provide some specific examples of other model modifiers that conflict with natural keys?
I suspect a mixin would do the trick just fine, and would be more natural than my proposed class decorator.
It's clearly been a while since I first had this need, but I think I'd had my own custom Model class that added some functionality I wanted, probably overriding the default objects
manager or something. I figured out a different approach for that so I could use this library, but requiring that my models inherit from NaturalKeyModel
rather than be able to construct my own superclass (or superclasses provide by other libraries) definitely limited the possibilities for mixing this library with other needs.
Adding a NaturalKeyMixin to this package would provide compatibility with models that inherit from GeoDjango models.
Requiring that a model inherit from NaturalKeyModel can conflict with other model modifiers that also requiring inheritance. It would be nice if the same functionality could be exposed via a class decorator. E.g.,