On Sun, 2008-04-06 at 11:39 -0700, Benjamin Wohlwend wrote: [...] > 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.
I think it's the right way to handle things if you need to be able to descend on an object-by-object basis. It's one query per object *if* you access something in the child class. But if you only need to test the type of the child, or *if* there's a child, it's free. > > 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). I'd be using "copy-on-demand" here, if it was me. If they try to edit a recurring date, create a single event from that recurring event for the particular date and give it a pointer back to the appropriate recurring event. So you can still - select all events that might occur on a given date (and filter further fairly quickly in Python to throw out the recurring events that don't occur). - select all events related to a particular recurring event if you're deleting it. - when deleting a single event, note that it's part of a recurring event and take appropriate related action. Alternatively, make everything a single event, but have a flag that points to an id for each recurring event. After all, it sounds like the only extra information in a recurring event is that it is recurring. So give all the single events that are part of one recurring event the same id value for a foreign key field (the RecurringEvent model is really just an id value, in that case). Anyway, there are obviously lots of choices here. Interval data and scheduling stuff are always a little fiddly in SQL, so there's going to be some thinking here. But you're not short of options. Regards, Malcolm -- If it walks out of your refrigerator, LET IT GO!! http://www.pointy-stick.com/blog/ --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
