These are chat archives for django/django
Hey guys - I have the following setup:
class BaseClass(models.model): … ref = models.ForeignKey(Source, related_name=‘data') class Meta: abstract = True class SampleTypeA(BaseClass): # …. class SampleTypeB(BaseClass): # ….
I have one abstract base class, which has a
Source and two classes of different sample types subclassing this abstract base class.
What I am trying to achieve is that I can access a collection of data samples, which either containes samples of type
SampleTypeB in my
Source instance via
Source exlusively comprises one type of sample. That is, it will either contain samples of type
SampleTypeA or vice verca.
When I’m trying to migrate, I’m getting a
reverse accessor error. I know why I’m getting this error and I know that giving both classes unique related names will solve this issue, but I’d like to keep the simplicity of not having to worry about which
related_name to call. For instance, if I went with
sample_type_b_data, I’d always have to check, whether my
Source contains data of
SampleTypeB and then return the apprioate related manager.
Another approach would be to smoosh everything into one class, but this isn’t the way to go as adding additional sample types would continually bloat up this class and it simply feels even worse than my first notion of having some property sort out which related manager to use.
Is there any (better) way to achieve this?
Ben Finney@deniz saner: “collection of data samples, which either containes samples of type
SampleTypeB” — how should the
Sourceinstance know which?
Ben Finneyi.e. what API on the
Sourceinstance do you expect, that will let you distinguish those two cases and other cases?
Sourcewill be instantiated with no samples at all. Serialized samples are fed into the app via REST, deserialized and then instantiated as the appropriate model class.
Source. But I know what you mean -
Source‘does not know in which table to look’. I came with this structure as I’m not aware that you can have dynamic models, where I can include / exclude model fields depending on some choice field, which may comprise the sample type :worried:
Ben Finney@deniz saner: Yes. And then, when the samples do exist, what API are you expecting so that
Sourcecan distinguish “either containes samples of type
Ben FinneyThat is, you've stipulated that there are those two cases (and obviously other cases could exist, such as a mixture of types). And you want
Sourceto be able to distinguish. How do you expect that to look, when using
Ben FinneyWhat guarantees that there will never be a mixture? Do you have a database constraint that forbids a mixture from ever existing?
Ben Finneyif not, you should code assuming that it could happen.
Sourceclass that I have, which I’d like to keep as generic as possible. That’s why I’d like to refer to my data samples as
temperature_dataor something else, as every source will always comprise a singular type of data
Ben Finney@deniz saner: I think the inheritance from an abstract base class is not what you want, then.
Ben FinneyIt seems as though you very much want to not have distinct model types. So, why not make it one model type, and distinguish the
source_typeas an enumerated value?
@matrixbot I’d love to have a single class for all samples. My optimal setup would be a model which, depending on the the
sample_type (something along the lines of ‘TEMP’, ‘MOTION’, ‘FLOW’ etc.) dynamically contains different fields, which are implemented in another class. The reason for this is that I’d like to omit a ‘one to rule ‘em all’ class, which bloats up as it needs to hold every single possible field. E.g., if a temperature sample would contain avg, min, max and power would have effective/reactive min / avg /max, the class would already be something like:
class Sample(models.Model): temperature_avg = temperature_ max = temperature_min = effective_avg = effective_max = effective_min = reactive_avg = reactive_max = reactive_min =
Moreover, it would be kind of inconsistent, if e.g. a power sample had blank fields to hold temperature data