I've been poking people on freenode#django about this, but nobody seems to have a good feel for the stuff i'm looking for.
For the record, I am working off of trunk (post-mr), keeping it regularly up to date. The crux of the problem is that we're using the Admin interface to administer a large number of companies and people. At the center of this is a many-to-many table containing addresses. Both Person and Company have Many-to-Many against this, in some cases as People and Companies (employer/employee) share an address. Some people or companies have multiple addresses as well. The address table contains 11000 rows, person is 12000, and company is 6000. There were two major issues that our users complained about when we first pushed the Admin at them: 1) When they see the Many-to-Many field on the person/company screens for Addresses; there are 12000 addresses on there: This doesn't work for them, adn is hard to see what addresses belong to people/manage existing. They weren't thrilled with the HORIZONTAL filter (which I thought was the 'right' solution), so we wrote a custom template tag that only displays the selected/linked addresses. We're working on a custom save method that finds duplicate 'new' entries and quietly replaces with an existing if there's a dup. 2) It's SLOW. I've tried this on a number of machines, including my new 2ghz dual core/2gig RAM Macbook, and loading the company or person screen takes 6-10 seconds. I sprinkled the Django codebase with debug/timing code and this is all when addresses is selected against, and the custom filter is run. Even if we are only displaying the selected addresses, it's sitll finding ALL the addresses and this is crawling. My ideal solution (I'm considering dropping admin and whipping something a bit more usable together, but I hate the idea) would be, for now, to do a select that ONLY selects the addresses currently associated with the person or company. I can deal with the 'dup' addresses issue later, as for now the 6-10 second load per screen has made the page unusable. I haven't been able to figure out however, without changing the core Django code (Which I'm trying to avoid doing) how to implement this. My understanding of the filter syntax is admittedly still rudimentary, but it doesn't look like limit_choices_to can do what I need. I have written a custom manager method that does it, and very quickly, but I don't know how to tell the admin to use it. I do see stubs in models.fields.related for 'lookup_overrides', however, nothing seems to hook into this attribute as of yet. Any thoughts, if you've survived my long rambling inquiry, into how to solve my problem? Is the admin simply not capable of handling this task? --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users -~----------~----~----~----~------~----~------~--~---
