These are chat archives for django/django
Ben FinneyA database model can't “dynamically contain different field” in a relational database.
Ben FinneySo the solution with separate subclasses, that Django handles quite well, is probably the best fit.
Ben FinneyWhen querying samples, you're going to have to deal with the fact it's not impossible that a
Sourceis referenced by multiple different
Samplesub-types. So your code will have to deal with that possibility: ask explicitly for “the set of this source's samples that are TemperatureSample`, and so on.
Ben FinneyThat's done by setting a sifferent related name from each specific model. Heed the warning at https://docs.djangoproject.com/en/1.11/topics/db/models/#be-careful-with-related-name-and-related-query-name
Ben Finneyso, @deniz saner, I appreciate that the current version of your Python code might try to ensure a Source only gets referenced by one Sample sub-type; but if you want to use a relational database, you'll need to allow for possible cases (including “the application had a bug that allowed mutlipel sample types to reference this source”) by coding your application to know what sub-set it's asking for.
Ben FinneyDjango is quite good at getting the object paradigm and the relational paradigm working together. Using sub-classes for specific sub-types of an abstract base model is pretty seamless.
Ben FinneyBut it can only guess so far. There's no way to make the ironclad promise that “every Source will never have Sample instances in the database of more than one type”, so Django can't assume that. It will require that each sub-type has a different related_name for an attribute on Source.
Ben FinneySo I think you're looking for an optimisation that isn't really an optimisation. The first time your database does realise that possibility – because of a bug, or because your design changes – you will be very glad you don't have to undo that assumption :-)