>> 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 [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?hl=en
-~----------~----~----~----~------~----~------~--~---