[MKDoc-dev] Events Component: Milestone 1 Complete

[Sam Tregar]

On Mon, 18 Oct 2004, Bruno Postle wrote:

> We generally assemble an sql script for this purpose, something like
> this (untested):
> 
>   CREATE TABLE IF NOT EXISTS Document_TimeRange (
>     ID int(11) NOT NULL auto_increment,
>     Document_ID int(11) default NULL,
>     FromDate datetime NOT NULL default '0000-00-00 00:00:00',
>     ToDate datetime NOT NULL default '0000-00-00 00:00:00',
>     PRIMARY KEY  (ID),
>   ) TYPE=MyISAM;

Sounds fine.  I'll add that to my todo list.

> This is fine, upgraders will just have to be made aware of the new
> dependency.  Though I am concerned that the timezone list might get
> too long - The full list of possible timezones offered when doing a
> Linux installation is enormous.

That's a reasonable concern, but I don't know how to address it.  Is
there anywhere in the world we can be sure our users won't want to
have an event?

> - I'd like the list of months to be defined in the template somehow
>   so it can be localised along with the rest of the user interface.
>   Chris, is this possible with Petal?

I can think of a couple ways to do this, although none of them are
particularly pretty.  It would be easier if Petal had expressions "if
month == 'January'".  It doesn't, right?

> - The 'minutes' field can be set to the nearest minute, is a select
>   list of 60 items too long?  or should we reduce it to 5 minute
>   intervals?

That works for me.

> - The times as stored in the database are normalised to UTC - I
>   assume this means that the 'canonical' data with timezone is
>   stored as XML in the component?

Right.

>   I wonder if the search indexer cronjob could manage updating the
>   Document_TimeRange table - Not necessary right now, but we have
>   had problems in the past when a form submission updates multiple
>   MySQL tables - This is where the indexer script came from in the
>   first place.

What problems did you have updating multiple tables?  Was it too slow?
I think updates to this table should be reasonably fast.

Actually, it occurs to me that I have no idea how big your client
sites are.  How many documents are in the largest MKDoc site?

-sam