Hi Daniel, > -----Original Message----- > From: Daniel Florey [mailto:[EMAIL PROTECTED] > Sent: Dienstag, 3. Februar 2004 17:47 > To: Slide Developers Mailing List > Subject: Re: proposal: integrate indexing - search > > > Hi Martin, > > Am Dienstag, 3. Februar 2004 17:07 schrieb Wallmer, Martin: > > Hi Daniel, > > > > > -----Original Message----- > > > From: Daniel Florey [mailto:[EMAIL PROTECTED] > > > Sent: Dienstag, 3. Februar 2004 16:27 > > > To: Slide Developers Mailing List > > > Subject: Re: proposal: integrate indexing - search > > > > > > > > > Hi, > > > great work. After reading it several times I understand > most of it :-) > > > As I'm working on events at the moment I think they could be > > > used to trigger > > > indexing for lucene based search. > > > They provide synchronous event collections (before commit and > > > vetoable) as > > > well as asynchronous event collections (fired after commit). > > > The collection can be filtered, so that only the desired > > > changes are indexed > > > > that could be a way to trigger the indexer. My current > thoughts are to > > trigger the indexer within the parent store > > (org.apache.slide.store.AbstractStore.java). Here we have a > good chance to > > let the indexer take part in two phase commit. It's up to > the indexer > > implementation, if two phase commit is used, or > asynchronous processing is > > done. I'm just on AbstractStore. > > I hope that that some day in the future someone will vote for > my event stuff > so that we can see if it fits to the needs of indexing.
I don't think anyone voted against events :-) > It should be possible to implements indexers that can take part in a > transaction so that search queries reflect that content that > was changed in > the transaction (as it possible with rdbms). But this should > be achieved by > the use of events as well. Two phase commit is very closely coupled to the stores, so I think the best place for indexing in a two phase commit scenario is in the store context. > The advantage of events is that > different aspects > of slide could be configured in the same way and can be > coupled loosely > without bloating up the core classes. its not too much bloating up :-) > Another advantage is that events could (in the future) be > distributed in a > clustered environment so that the search index could be > clustered as well > (just brainstorming). Yes! We should stay open for that. How the indexers interface should look like for the event driven solution? If we agree to a common interface, why not stay open for both approaches? Regards, Martin --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
