Opened 18 years ago

Closed 17 years ago

#2197 closed enhancement (wontfix)

[patch] Generic search interface

Reported by: Matias Hermanrud Fjeld <mhf@…> Owned by: nobody
Component: Database layer (models, ORM) Version:
Severity: normal Keywords: feature_request
Cc: Triage Stage: Design decision needed
Has patch: yes Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no

Description

This patch moves searching from the admin interface to querysets, and implements searching in django.views.generic.list_detail.object_detail.

All querysets get a new search()-method, wich takes a query string and optionally a list of fields to search. By default the fields in model._meta.search_fields
are searched.

The patch is backwards-incompatible. The search_fields-option goes in Meta instead of Admin:

class Toy(models.Model):
    name = models.CharField(maxlength=50)

    class Meta:
        search_fields = ['name']

    class Admin:
        pass

When fetching objects, one can do:

from myapp.models import Toy

# i like things that roll
Toy.objects.search('ball wheel')

Please comment.

Attachments (1)

generic-search.diff (12.8 KB ) - added by Matias Hermanrud Fjeld <mhf@…> 18 years ago.

Download all attachments as: .zip

Change History (8)

by Matias Hermanrud Fjeld <mhf@…>, 18 years ago

Attachment: generic-search.diff added

comment:1 by Matias Hermanrud Fjeld <mhf@…>, 18 years ago

Summary: Generic search interface[patch] Generic search interface

comment:2 by django@…, 18 years ago

I like that, it allows easy search functionality in views.

I would prefer to have an optional search_fields in the admin class, which is by default the same as the meta search_fields. The admin pages use them, if they are defined or try to fall back to meta. If search_fields in admin is defined but empty or None, search in admin is disabled. Not everybody wants to allow search over fields that the user will not see, but an admin does and wants to search for (this could cause security problems)

comment:3 by Adrian Holovaty, 18 years ago

I'm -0 on this, because it seems like that's overloading the database API with corner case stuff.

comment:4 by blinks@…, 17 years ago

[It] seems like that's overloading the database API with corner case stuff.

Creeping featurism at its worst. The problem is that while a generic database search is something that quite a few people have requested (I've implemented a (terrible) hack on my own app, for instance), it's a massive piece of functionality. Hey, Google's entire business is built on making arbitrary search work correctly.

Summary: A generic search consisting of just a Model.objects.filter(field__icontains=query) might be a nice start, but doesn't provide any ranking of results. A more complete version of a search interface would be a nice feature, but take too many resources.

comment:5 by Simon G. <dev@…>, 17 years ago

Triage Stage: UnreviewedDesign decision needed

I think this is a wontfix based on the comments above, but I'll pass it on to D.D.N. because http://code.djangoproject.com/wiki/TextIndexingAbstractionLayer looks a long way off.

comment:6 by Philippe Raoult, 17 years ago

Keywords: feature_request added

comment:7 by James Bennett, 17 years ago

Resolution: wontfix
Status: newclosed

Since this hasn't gone anywhere and Adrian was against this idea for implementing it, I'm marking wontfix.

Note: See TracTickets for help on using tickets.
Back to Top