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

Cyrus Daboo cyrus+lists.cosmo at daboo.name
Tue Feb 14 17:55:05 PST 2006


Hi Brian,

--On February 14, 2006 1:49:58 PM -0800 Brian Moseley 
<bcm at osafoundation.org> wrote:

> 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).

So do you have the Jackrabbit xpath queries acting directly on the database 
entries? I know previously lucene was being used to index the actual node 
content and properties etc. Also, you'll have to figure out an appropriate 
way of doing the time-range expansion/comparison stuff too.

-- 
Cyrus Daboo




More information about the Cosmo mailing list