Hi Malcom, thanks for your thorough answer!
On Apr 6, 6:29 am, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote: > On Sat, 2008-04-05 at 02:49 -0700, Benjamin Wohlwend wrote: > > > I'm tending to the second design, since I would be able to combine > > both event types in a single queryset. > > Well, probably not as you would expect. If you do a query on the Event > model, even with model inheritance in place, you will get back a bunch > of Event objects. Not a collection of SingleEvent and RecurringEvent > objects. That is, Django will only query the Event table (working out > the types of the most descended model possible is an ineffecient query). > > You can get from an Event to a SingleEvent or RecurringEvent, via an > attribute, but what you can't tell easily is whether the particular > Event is the parent of a SingleEvent or the parent of a RecurringEvent. That's what I found out pretty soon after trying to implement it. I 'solved' it by storing the type of the child event in the Event table and, if necessary, descending to the particular event, depending on the stored type. This works well, however I think this approach is first of all a hack and second of all probabely quite query-intensive. > > It depends a bit on what you're wanting to use this data for. There was > quite a discussion about modelling this sort of information a year ago > on this list that might be of interest to you. > Seehttp://groups.google.com/group/django-users/browse_frm/thread/ed0dc08...for > the full thread. > > I feel that the modelling discussed there is probably a bit more > appropriate for this sort of problem that recording a row for every > single occurrence. Rather, store the event, some auxilliary stuff like > start and end and repeating recurrence. It's then not too hard to pull > out a bunch of candidate events for any given date and filter them > further in Python (perhaps via a method on the model) to see if they > occur on the date you're interested in. Basically, moving a bunch of the > computations into Python and out of the database, which isn't a crazy > idea. The problem with this design is that recurring events are more or less copies of the original single event. I'd really like to keep my recurring events editable (i.e. if the user wants to add information to the description of one recurring event while leaving the original event and the other recurrences alone). My, again quite hackish, solution for this particular problem was to use properties on the RecurringEvent, which return the attribute of the related single event if the own attribute is NULL/None. It works for my use case so far, but of course things like forms.ModelForm ignore such ugly trickery. Anyway, I'll probably contemplate a few more hours over this question as I've got a bit of a bad feeling in the gut with my current solution. Thanks again, Benjamin --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
