[Cosmo] Re: indexing all components in a calendar resource?

[Brian Moseley]

On 2/14/06, Cyrus Daboo <cyrus+lists.cosmo at daboo.name> wrote:

> You will have to change the indexing scheme to explicitly exclude (or
> implicitly include) set properties, and then modify the query code to spot
> queries against non-indexed items and fall back to brute-force iteration
> over all resources. If you do that, the key thing is to ensure that the
> indexes can be easily upgraded to add more properties in the future if
> needed. Ideally a 'just-in-time' incremental index update procedure would
> be good but a little complicated.

because of bug 5014
(<https://bugzilla.osafoundation.org/show_bug.cgi?id=5014>), we're
modifying the "virtual property indexing" approach. we're still going
to flatten the icalendar components as you've done, but instead of
using a text filter to index them, we're going to store them directly
as jcr properties of the calendar resource node.

this approach is a compromise between our original "store all
icalendar data in a big subtree of the resource node" implementation
and the current approach. it will result in more stored data, but not
that much more for most normal resources, especially if we leave out
the vcalendar and vtimezone properties. we'll be able to guarantee
data consistency on PUT tho, and all of our data will be manageable
via rdbms vendor-supplied tools (currently we'd have to craft custom
tools to backup the lucene indexes, whereas with the new approach we
can lose and regenerate them as necessary, since they aren't the
source of truth anymore).

sorry that i haven't communicated this decision to the mailing list.
bkirsch, bobbyrullo and i discussed it at length in irc yesterday if
anybody wants to have a look at the transcript.

in any event, cyrus, everything you've said matches with my own
understanding, so i'm pretty confident i haven't missed anything in my
analysis :)