Help with subclasses approach and question about django-polymorphic

Hey everyone.

I’m on a situation where I’m building a project that’s gonna have two big branches. One that’s gonna be open-source for everyone, and another that’s gonna have our company custom stuff, with extra business logic, extra views, and stuff like that.

We decided that this extra stuff is going to be inside of one or more extra apps that we can use to add as modules, for example, extra views that we would need but we don’t think the rest of the world would be interested in.

If we just used views that would be no issue, but we thought it would be a good idea to use subclasses so they can also contain extra attributes and methods and we would have a setting for each of these classes so we can select to put an example, if we have a class “Contact”, if we want to use the default Contact model, or any custom one.

That leads me to a question wondering what I’m going to do with foreign keys, especially in the case I wanted for example to make two subclasses: SpecialContact as a subclass of Contact, and SpecialAddress as a subclass of Address. Is there a way to tell on the main applications, that this Contact’s “address_set” has to be SpecialAddress? Or do I have to use similar related_names? Or can I also store this related_manager somewhere else to tell the views which one I have to use? There’s also the issue for example if I wanted to use regular Address with a SpecialContact, how could I use a relation manager to tell the Address that I want to bring its SpecialContact set rather than the regular Contact set?

Also, while learning stuff for this, I stumbled upon a package called django-polymorphic, which at first sight seems to be really good for a problem like mine, but I know no projects that use it, and if it is recommended by some, if it has any problems, etc. But it seems to be really good for not being necessary to touch the main views, not being necessary to select beforehand which are the preferred classes that we want to use.

The questions would be:

  • Have you ever stumbled upon this situation? What approach would you recommend for this?

  • Have you ever tried this django-polymorphic package? Is it worth to make my models polymorphic just in case someone wants to subclass them later to add more logic to the models by making subclasses?

  • The issue with the related manager described above.

Thanks a lot and have a great day.

I haven’t encountered this type of situation, and I have no idea whether or not this would work, but if I had to try something, I’d take advantage of Python’s import as statement to hide base objects.

In other words, I’d try something like:

class BaseContract(models.Model):
    ... fields defined, etc

as the standard Contract. Then I might have:

class MyContract(BaseContract):
    ... extensions to BaseContract

Then, in all appropriate places, you import the appropriate class as either:
from something.models import BaseContract as Contract
or
from app.models import MyContract as Contract

This does require massive sets of changes each time you add a new flavor of one of your classes.

I guess with some metaprogramming you could do this in a more dynamic manner - I’m not sure how that would look.

Hope this gives you some ideas.