>> events = {} # or SortedDict if order matters >> + new_lists = 0 >> + appended_lists = 0 >> for event in future_events: # one DB hit here >> - region = event.club.region >> + region = str(event.club.region) >> + if region in events: >> + appended_lists += 1 >> + else: >> + new_lists += 1 >> ev_list = events.get(region, []) >> ev_list.append(event) >> events[region] = ev_list >> + assert False, '%i created, %i updated, %i total' % ( >> + new_lists, appended_lists, len(future_events)) > > Interesting... as long as select_related was on there, it only picked > up 4 events. Remove it, and it gets all 13. Weird.
I second the weirdness. I'd try tossing an assert False, len(future_events) immediately after the future_events = Event.objects.select_related().filter(...) statement to see what Django thinks it's bringing back for future events. > It wasn't anything to do with region, which isn't another table, it's > just a field under Club with choices (since they'll basically never > change) ah...helpful to know. So from what I've discerned from your models, you have something like class Club(Model): REGIONS = ( ('NE', 'NorthEast'), ('PAC', 'Pacific'), #... ) region = CharField(..., choices=Club.REGIONS) name = CharField(...) class Event(Model): club = ForeignKey(Club) # FK or M2M? start_date = DateField(...) Anything important I'm missing here? I'm not sure why it's not behaving properly with the select_related, as that should allow you to pull back the whole bunch in one query (as opposed to performing a query for each event). -tim --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---