>
> 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 <osezel...@gmail.com> 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 django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@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
> <https://groups.google.com/d/msgid/django-developers/25f67fd1-4dfa-439d-91c6-356716da950b%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
> 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 django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@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/CAMyDDM3LsVvjYJQfXiJu9KNaPbpES5Vm6biKUr%3DREZz5hEH9%2BA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to