Inconsistant MRO in BaseDateListView and BaseDayArchiveView

[django@…]

I have a class like this:

class ReportView(DateDetailView, BaseDayArchiveView, BaseMonthArchiveView):

Which raises an exception: Cannot create a consistent method resolution order (MRO) for bases DateMixin, ContextMixin

This is due to the order of basses on BaseDateListView. I've attached a patch that solves the problem.

It's useful for showing the details of one object, with a list of other related dated objects.

[django@…]

Patch

[Marc Tamlyn]

I would be generally worried about what you're trying to do here. There's a *lot* of pieces of functionality in this code you're trying to use at once. In particular, you've got both SingleObjectMixin and MultipleObjectMixin in your class hierarchy. Also, you've got multiple implementations of get_dated_items.

This seems a heavy edge case to me. I think it's the territory you should be writing your own view rather than trying to to mix together the pieces Django provides. You may have more luck composing the lower level components of the views you're using at the moment so you have better control over the MRO.

I'm going to close this, as we simply can't support every possible inheritance scenario. The patch is pretty innocuous, but the motivation is flawed.

[django@…]

I'm aware of the multiple get_dated_items. I have get method which avoids super calls for this reason. It's expected that a class with a diamond dependency graph will resolve conflicts between the base classes. With the MRO conflict resolved the code works fine. I have a view which shows a report, a list of reports on the same day, and a calendar with links to the other days that have reports:

    def get(self, request, **kwargs):
        self.object = self.get_object()
        self.date_list, self.object_list, extra_context = BaseDayArchiveView.get_dated_items(self)

        context = self.get_context_data(object_list=self.object_list,
                                        date_list=BaseMonthArchiveView.get_dated_items(self)[0],
                                        object=self.object,)
        context.update(extra_context)
        return self.render_to_response(context)

It may be strange, but it's very powerful to be able to piece views together. Just these six lines of code and I've got the page described above. Thanks for your time looking at my patch.