At 04:37 AM 9/5/99 +0900, somebody wrote:
Event ZClass (inherits from CatalogAware, ObjectManager) - EventDate ZClass (may inherit from CatalogAware for doing date-range manipulation)
Event could have a function, as Itamar suggested, that zips through the EventDate objects (<dtml-in "objectValues('EventDate')">) and sees if there is a match.
Or, you could grab all matching EventDate objects (through the Catalog) and then use parent[1] to get the Event info.
This is a one-to-many relationship with no redundancy, and it should perform pretty well, I think.
I've given the subject of events quite a bit of thought. In addition to the one-up, recurring, and range problems, there is also the small matter of timezones, and efficient searching for what items should be displayed on what 'day', even though what constitutes a 'day' differs for different timezones. My thoughts go like this: * Events, Meetings, and the like may have a 'Schedule' object associated with them. The Schedule contains zero or more CalendarEntry objects. * CalendarEntry objects model a single UTC timespan - i.e. a start and stop timestamp. They provide a (multivalued) calendar_date attribute which can be cataloged. calendar_date is a list of all the dates (in UTC terms) which the event intersects. (Note that this requires ZCatalog to support a 'MultiValueIndex', which it doesn't yet. I say 'yet' because it's something I want to code up when I get around to it. It looks like a pretty trivial addition.) * When displaying a calendar, search for CalendarEntries with calendar_date values for both the desired day, and either one day forward or one day back from the desired day, depending on your relative timezone to UTC. Then look at the start/stop timestamps of the entries to weed out items which aren't really a match. * Because CalendarEntries (and the Schedules that contain them) acquire attributes and methods from their containing Event, Meeting, or whatever, they do not need to contain any other data, unless there are more specific notes. If a particular calendar wants to work its way upward through the acquisition tree to provide a broader view of an event, with many scheduled items for the same day (e.g. a seminar with lots of classes), it can do so. * To handle recurring events, give Schedules the ability to generate recurring CalendarEntries by way of a dialog that asks for a highest and lowest date to generate, and the parameters for recurrence. This method would just create the requisite CalendarEntries, and perhaps store the data used to generate them to be used as a default for the next time the generation needs to be run. Ideally, it would save the next value that should be used for a start date. * If Schedules are ObjectManager derivatives, it should be possible to easily view/add/edit/delete individual CalendarEntries from the Schedule. I think that about covers it. Notice, by the way, that it really doesn't matter where you put a Schedule object. It could be attached to anything that needs a schedule, like a room, a person, a project... If Schedules have a property that determines whether conflicts are allowed, so much the better. Schedules could also provide some basic views to display themselves nicely. The only other thing I can think of, is to allow CalendarEntries to be crosslinked between different Schedules, and changed as one. This would allow, say a Meeting or Conference's Schedule to have a CalendarEntry which also appears in a MeetingRoom's Schedule. This is technically possible in the ZODB, but in practice, the issue of asking all the Schedules to approve a change before committing, is a bit tricky. If it could be done, however, it would be a *way* cool thing. Not that all the preceding isn't pretty cool on its own.
gotta admit that a lot of my bias towards the rdb is based on the fact that mysql (our weapon of choice) has proven itself to be an incredible speed daemon (i mean, they sacrifice transactions, which i don't need, in the name of speed).
Interestingly, you *can* do transactions in MySQL, if you do them at a higher semantic level. For example, you could build a ZODB Storage implementation based on MySQL that supported Zope versioning and undo as well as transactions, all without MySQL needing transactions. Of course, arguably what you'd have when you did that would not really be a relational database at all... :)