Possible Django bug I am considering raising

[OwlHoot]

Hi all

I believe the issue I have enquired about on the following Stack Exchange page :

https://stackoverflow.com/questions/62162288/baffling-error-filtering-django-objects-of-derived-class-by-values-in-foreign-ke

may well be a Django bug, or at the least no longer works with Django as this has evolved since v 1.10 (when it worked fine).

In summary, the issue is that if a model class B inherits from A, which inherits from models.model, then a call to B.objects.filter() cannot locate a field actually defined in B (because, it seems, Django starts its walk through the relevant/related models from A rather than B and for some unfathomable reason checks everything _except_ B !)

Regards

John R Ramsden

[Tim Graham]

You can try to find the commit that introduced the issue: https://docs.djangoproject.com/en/dev/internals/contributing/triaging-tickets/#bisecting-a-regression

[OwlHoot]

On Thursday, 4 June 2020 23:45:53 UTC+1, Tim Graham wrote:

You can try to find the commit that introduced the issue: https://docs.djangoproject.com/en/dev/internals/contributing/triaging-tickets/#bisecting-a-regression

I'm happy to try and do this, i.e. produce a simple test case that fails, and then find the commit that first caused this, provided I am assured that if I can then a Django maintainer/developer will jump on this and fix it pronto!

If the result will be added to some list where someone will think about maybe fixing it in six months, and then only if anyone else complains, I'll have long since moved on to another project and/or another client and the issue will be of no interest to me.

 

[René Fleschenberg]

Hi,

the code you posted on stackoverflow is not sufficient to reproduce the
problem. It would be good to provide a minimal reproducible example (see
also https://stackoverflow.com/help/minimal-reproducible-example).

Regards,
René

[Ramiro Morales]

Remember you can not juat open/report an issue and bisect the git commit which could have introduced the change in behavior, but also, if it gets confirmed as a real bug, you can fix it yourself so to not delay yourself in your current project. With the nice side effect that the fix will benefit many others.

Another option would be: If you can't or don't want to do what I suggest above then Are you willing to commit to funding another Django contributor to get this immediate attention & personalised service so to be able to solve the issue affecting your current project/client?

--
You received this message because you are subscribed to the Google Groups "Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-users...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/016c2855-ec5e-4880-ac18-c4f5660732dbo%40googlegroups.com.

[OwlHoot]

On Thursday, 4 June 2020 16:25:09 UTC+1, OwlHoot wrote:

I believe the issue I have enquired about on the following Stack Exchange page :

https://stackoverflow.com/questions/62162288/baffling-error-filtering-django-objects-of-derived-class-by-values-in-foreign-ke

By adding some debug code in /usr/lib/python3.6/site-packages/django/db/backends/base/creation.py I have made some progress with this "bug" (which I am no longer convinced it is).

The issue relates to a load of derived classes, as follows :

    class DataSet(models.Model)

    class PSessionDataSet(DataSet)

       :::

    class FilteredDataSet(DataSet)

    class AggregateDataSet(DataSet)

   class SurveyRunDataSet(DataSet)

   class RestrictedDataSet(SurveyRunDataSet)

These all have the same app_label value ("dataset") in their Meta class, and are thus in the same "group" of models.

However, the debug logging line reveals that Django thinks all these classes share the same default manager (_default_manager), namely dataset.AggregateDataSet.objects:

            Model                                                            Default Manager
             :::
    app.survey.models.grid.GridRow                                       survey.GridRow.objects
    app.analysis.models.Analysis                                         analysis.Analysis.objects
    app.analysis.report.models.AnalysisReport                            report.AnalysisReport.objects
    app.analysis.dataset.models.dataset.DataSet                          dataset.AggregateDataSet.objects
    app.analysis.dataset.models.survey_run.SurveyRunDataSet              dataset.AggregateDataSet.objects
    app.analysis.dataset.models.filtered.FilteredDataSet                 dataset.AggregateDataSet.objects
    app.analysis.dataset.models.restricted.RestrictedDataSet             dataset.AggregateDataSet.objects

Now I know the documentation says the default manager is chosen as the first it happens to come across in the model group. But that sounds absolutely barking mad. Shouldn't each of these models have their own model-specific default manager, as all the models preceding the "dataset" models do in the above table?!

Otherwise surely the manager will have trouble finding various columns/values in a model table other than the one on which it is based, which is exactly the error I am seeing!

So now my problem becomes how to tweak each of these "dataset" models so their default managers will become as follows :

            Model                                                            Default Manager
             :::
    app.survey.models.grid.GridRow                                       survey.GridRow.objects
    app.analysis.models.Analysis                                         analysis.Analysis.objects
    app.analysis.report.models.AnalysisReport                            report.AnalysisReport.objects
    app.analysis.dataset.models.dataset.DataSet                          dataset.DataSet.objects
    app.analysis.dataset.models.survey_run.SurveyRunDataSet              dataset.SurveyRunDataSet.objects
    app.analysis.dataset.models.filtered.FilteredDataSet                 dataset.FilteredDataSet.objects
    app.analysis.dataset.models.restricted.RestrictedDataSet             dataset.RestrictedDataSet.objects

Would that just be a matter of adding lines as follows (typically in the FilteredDataSet class) :

  objects = FilteredDataSet.Manager()

or does one need a more elaborate overriding of get_queryset() ?

Any ideas gratefully received.

?