[Cosmo-dev] hibernate prototype

[rletness at simdeskcorp.com]

Brian Moseley wrote:

>
> did you notice that we're only expanding recurring events out to 2008?
> :) before that we were going to i think 2050, and that was causing
> PUTs of these events to take several seconds.
>
> something to consider for later, assuming we adopt the prototype, is
> how to handle infinitely recurring events (or even ones that recur
> past 2008). clearly it's tempting to index everything at write time,
> but at least with jcr, that had severe performance implications. we
> considered strategies like expanding two years at write time and then
> doing some sort of "just in time" expansion when servicing queries for
> time ranges that are outside that two year segment. love to hear any
> ideas you have.
>
Yeah I saw that.  One way to solve this is to just not allow recurring 
events
that go past a certain number of recurrences.  What percentage of events
are infinitely recurring??  It has to be very small.  The other idea I 
had was
instead of indexing time ranges, just compute a start and end date (could be
infinity) based on the recurrence rules.  This range would be computed and
indexed at creation time.  This means a database query gets a superset of
the events you are interested in.  Recurring events returned as part of a
time-range query would be passed through some business logic to filter out
events that don't  have a recurrence in the timerange.  This works for 
simple
time ranges,  but when you have nested timeranges, like you can in a caldav
calendar filter, it gets complicated. 

Because infinitely recurring events are such a small percentage of events
it would suck to have to implement such complicated logic just for that.

> have you seen commons-id? we're using it to generate uuids for scooby.
> maybe you can replace jug with it? i've never heard of jug, do you
> have a link?

I'll check it out...and probably just swich to using commons-id to make 
it easy.
Here is a link to jug:  http://jug.safehaus.org/

-Randy