On 12/1/07, Julien <[EMAIL PROTECTED]> wrote: > > The ticket http://code.djangoproject.com/ticket/3397 is looking at > that issue and seems to provide a good alternative for ordering non-db > fields. Is that patch viable?
It's viable for a very limited use -- if you can specify a real database field to sort on for your non-database-field-based model field. The example given in the docs ( http://www.djangoproject.com/documentation/model-api/#list-display) shows how you can sort a field that returns a database field surrounded by some HTML markup by specifying the real database field in admin_order_field. Essentially your non-db field has to map directly to a db field for this to be of use. (The state of that ticket is rather odd. The original patch was checked in and the ticket closed, a problem was found with the patch and the ticket was reopened, a patch for the problem was supplied, checked in, and the ticket was closed again, another problem was found and the ticket reopened, another patch supplied, that patch was checked in in r5799, but the ticket was not closed. Instead a comment was made that there ought to be tests for this, but since the feature is already in the code there is apparently little interest in writing tests for it, so it remains open although the feature is already in the codebase. The very last comment, with about 200 revisions worth of log messages -- I don't understand at all why that is there.) On Dec 2, 3:03 pm, Julien <[EMAIL PROTECTED]> wrote: > > Hi all, > > > > I find that displaying non-db fields is quite useless if you can't > > order/filter them... > > > > How would you approach the filtering and ordering of non-db fields in > > the admin interface? Would you try to customize the newforms-admin > > (and if so, how?) or add a built-in feature in the admin code? > > > > The way I see it is that dealing with non-db fields would involve > > fetching all the data from a given table and then ordering/filtering > > at a python code level. This would probably not be as fast as if done > > at a database level, especially if the table contains thousands of > > records, but at least that would give the ability to extend the use of > > non-db fields. > > For my own DB this would be a complete non-starter. Though not that big in absolute terms it has one table with >100,000 records and one creeping up to the million-record mark. Anything that does a "fetch all rows" brings my machine to its knees. Sure, I could just avoid using a feature based on this approach (like I avoid creating select box drop-downs with gazillions of choices in admin by using raw_id_admin), but if effort were to be expended on solving this problem I'd rather approach it by seeing if there isn't some way to communicate to the django code the SQL bits needed to do the kind of ordering desired. Of course in taking this approach I'm assuming there is some way describe the field and its ordering in SQL, which may not be true for all non-db-based fields, but happens to be the case for the ones I have that I'd be interested in sorting on. > Please let me know your thoughts on this and/or pointing me to some > > other similar discussions in the mailing list or elsewhere. I don't actually recall this coming up before, but I could have missed it or arrived later. I do have a field or two in my own use of Django where this would be a nice-to-have, but I've never had enough of a need for it to ever think seriously about how it might be done. Karen --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~----------~----~----~----~------~----~------~--~---
