>> (with several hundred clients, drilldown >> would be nice). > > Indeed. I think you may want to look a the newforms-admin branch. I > think the most natural would be to add auto-complete filters and > multiple applied filters. > Also, perhaps data_hierarchy will help in the short term: > http://www.djangoproject.com/documentation/model-api/#date-hierarchy
data_hierarchy or date-hierarchy? if only it was the former rather than the latter :) yes, this works nicely when the hierarchy is date-related, but dates aren't the only hierarchies. I've got customers who have accounts with providers and there are phones on each of those accounts. So rather than "YYYY -> MM -> DD" hierarchy, it would be nice to have "Customer -> ProviderAccount -> Phone" hierarchy or "Customer -> ProviderAccount -> Billing Statement" hierarchy. Databrowse may be my friend here, presuming Adrian followed through on his threats to add pagination. Definitely need pagination there ;) >> -be careful with tracebacks if, for some reason, you have a >> query-set that brings back bajillions of records and you error > ... > Yeah, I don't really know what to do with this. It's hard to know how > big something is (memory-wise) in python, and the debugging handlers > is necessarily generic. When I recognize the problem, I tend to try and filter the record-set before my crash-able code down to something more manageable. Not always possible, and it tends to be reactive rather than proactive, but it helps. Karen Tracey also suggested using a QuerySet wrapper that prevented it from returning gobs of data when I mentioned this problem on the list a month or two ago (Subject: "Preventing tracebacks from pulling back gobs of data" if one's looking for the thread) >> -the default admin tool is good for blogs, bad for bajillions of >> records. This might be mitigated a bit with some judicious use >> of limit_choices_to but I haven't mastered such yet > > raw_id_admin is your friend. > Again, I'd like to do an auto-complete widget here some day... needing our data-entry folks to memorize IDs would give me more grief that I need/want ;) So limit_choices_to combined with some hypothetical solution to the hierarchy problem above would produce an elegant solution. Auto-complete would also be helpful, though might require JavaScript enabled which not all of our devices support or have enabled. >> -PostgreSQL can do dumb things with your queries, which a little >> jiggering/subclassing of the query object can mung into something >> a little smarter (and much faster-running) > > Hmm. Can you give some examples? Are you saying the query planner is > missing indexes or...? I haven't had this problem yet, but I bet it > sucks. :) I think this was a PG thing, as the SQL query I would have hand-coded was the same query that Django created according to my query logs. I merely[*] had to invert some logic, moving it into the ON clause of a join. It produced about the same results, but instead of taking 5-10 minutes to run the query, it took 5-10 seconds. I did EXPLAINs out the wazoo, checked and double-checked my indicies, and shot a week trying to figure that one out. I chalk it up to PG-optimizer hiccups. I can give query details if you're obcenely curious, but it certainly didn't appear to be Django's fault. -tkc [*] merely = rewrite my own Q() object to muck with the internals of the query, which comprised about half of that week of time. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@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-users?hl=en -~----------~----~----~----~------~----~------~--~---
