These are chat archives for django/django

1st
Dec 2017
Deniz Saner
@denizs
Dec 01 2017 10:10

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 ForeignKey to 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 SampleTypeA or SampleTypeB in my Source instance via Source.data.all(). A 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_a_data and sample_type_b_data, I’d always have to check, whether my Source contains data of SampleTypeA or 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?

matrixbot
@matrixbot
Dec 01 2017 10:32
Ben Finney @deniz saner: “collection of data samples, which either containes samples of type SampleTypeA or SampleTypeB” — how should the Source instance know which?
Ben Finney i.e. what API on the Source instance do you expect, that will let you distinguish those two cases and other cases?
Deniz Saner
@denizs
Dec 01 2017 10:36
@matrixbot What I mean is that each Source will 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.
What’s more, it’s one sample type per 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:
matrixbot
@matrixbot
Dec 01 2017 10:40
Ben Finney @deniz saner: Yes. And then, when the samples do exist, what API are you expecting so that Source can distinguish “either containes samples of type SampleTypeA or SampleTypeB”?
Ben Finney That 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 Source to be able to distinguish. How do you expect that to look, when using Source?
Deniz Saner
@denizs
Dec 01 2017 10:41
That’s the point - I don’t want to distinguish. Source will either have sample type a or b - never mixed. That’s why I’d like to have a consistent API
matrixbot
@matrixbot
Dec 01 2017 10:42
Ben Finney What guarantees that there will never be a mixture? Do you have a database constraint that forbids a mixture from ever existing?
Ben Finney if not, you should code assuming that it could happen.
Deniz Saner
@denizs
Dec 01 2017 10:43
I completely control the data flow into the DB and raise exceptions on a model creation level
Think sensors. A motion sensor will never send temperature samples, but temperature samples may comprise other attributes than motion samples. Generalising these sensors leads to the Source class 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 data rather than temperature_data or something else, as every source will always comprise a singular type of data
matrixbot
@matrixbot
Dec 01 2017 10:55
Ben Finney @deniz saner: I think the inheritance from an abstract base class is not what you want, then.
Ben Finney It 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_type as an enumerated value?
Deniz Saner
@denizs
Dec 01 2017 11:16

@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

Felipe Campelo
@fccampelo
Dec 01 2017 15:02
hey guys
i have a simple problem