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

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

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

Osezele Orukpe
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'

--
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 [hidden email].
To post to this group, send email to [hidden email].
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.
Reply | Threaded
Open this post in threaded view
|

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

Alasdair Nicol
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

On Wednesday, 2 January 2019 12:24:00 UTC, Osezele Orukpe wrote:
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'

--
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 [hidden email].
To post to this group, send email to [hidden email].
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/ffa51fce-b9c8-4d52-bb10-fd75ff503bd0%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

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

Adam Johnson-2
In reply to this post by Osezele Orukpe
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!

On Wed, 2 Jan 2019 at 10:58, Osezele Orukpe <[hidden email]> wrote:
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'

--
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 [hidden email].
To post to this group, send email to [hidden email].
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

--
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 [hidden email].
To post to this group, send email to [hidden email].
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/CAMyDDM3LsVvjYJQfXiJu9KNaPbpES5Vm6biKUr%3DREZz5hEH9%2BA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

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

Osezele Orukpe
In reply to this post by Osezele Orukpe
Thanks for this information


On Wednesday, January 2, 2019 at 1:24:00 PM UTC+1, Osezele Orukpe wrote:
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'

--
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 [hidden email].
To post to this group, send email to [hidden email].
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/aee6866a-775f-4b5f-b059-2c9fb0cd5321%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.