[Feature Request] DetailView, DeleteView, UpdateView should not work with only slug and primary key field?

133 views
Skip to first unread message

Osezele Orukpe

unread,
Jan 2, 2019, 7:24:00 AM1/2/19
to Django developers (Contributions to Django itself)
Django class based generic views like DetailView, DeleteView and UpdateView should be flexible enough to work with any unique field not just slug and primary key field,
In real projects primary key and slugs are  not used fetch data, a more abstract unique key is preferred.
Yes, this can be easily done on our own but django can just ease that extra stress by making these generic classes flexible enough to work with any field of our choice in
the model given that the field is flagged as a unique field.

so we could just use the DatailView as so:

ProductDetail(DetailView):
    model = Product
    field = order_id

instead of having to write a custom query(with the ORM) to fetch with 'order_id'

Alasdair Nicol

unread,
Jan 2, 2019, 9:16:33 AM1/2/19
to Django developers (Contributions to Django itself)
Hi,

You can already use any unique field as the slug field, for example:

    path('product/<slug>/', views.ProductDetail.as_view()),

    ProductDetail(DetailView)
        model = Product
        slug_field = 'order_id'

If you want to use a different name in the URL pattern, then set slug_url_kwarg [1].

    path('product/<order_id>/', views.ProductDetail.as_view()),

    ProductDetail(DetailView)
        model = Product
        slug_field = 'order_id'
        slug_url_kwarg = 'order_id'

Cheers,
Alasdair

Adam Johnson

unread,
Jan 2, 2019, 9:34:24 AM1/2/19
to django-d...@googlegroups.com
In real projects primary key and slugs are  not used fetch data, a more abstract unique key is preferred.

In my experience it's normally primary key that is used. In a recent project, I've used hashid fields as primary keys to avoid the problem of leaking database PK's, which is the main motivation to use other keys: https://github.com/nshafer/django-hashid-field 

What you're suggesting isn't much code and the existing view hierarchy lets you add it pretty easily in your own DetailView class by overriding just get_object, something like (untested):

from django.views.generic import DetailView as BaseDetailView


class GetObjectByFieldMixin(object):
    def get_object(self, queryset=None):
        if queryset is None:
            queryset = self.get_queryset()
        
        try:
            return queryset.get(**{self.field: self.kwargs['field_id']})
        except queryset.model.DoesNotExist:
            raise Http404('...')


class DetailView(GetObjectByFieldMixin, BaseDetailView):
    pass

I am also one of several who believe the built-in class based views are complicated enough and I would be against increasing this complexity when it's easy enough to override for your project.

I'd also like to point out Tom Christie's project http://django-vanilla-views.org/ which I've used and have helped maintain, it has a simpler class-based view hierarchy and has built-in support for what you want (at the expense of ditching Django's pk-or-slug-or-both options). With it you can do something like:

from vanilla import DetailView
from myapp.models import Product


class ProductDetail(DetailView):
    model = Product
    lookup_field = 'order_id'

HTH!

--
You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-develop...@googlegroups.com.
To post to this group, send email to django-d...@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/25f67fd1-4dfa-439d-91c6-356716da950b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


--
Adam

Osezele Orukpe

unread,
Jan 2, 2019, 6:15:40 PM1/2/19
to Django developers (Contributions to Django itself)
Thanks for this information
Reply all
Reply to author
Forward
0 new messages