Hi Martin, sorry... I've overlooked this mail so I answered to another one.
Am Mittwoch, 4. Februar 2004 10:18 schrieb Wallmer, Martin: > 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 :-) But nobody voted for them... :-( > > > 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. I've to think about how this can be achieved by events... > > > 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? What about something like this: public interface ContentIndexer extends ExpressionFactory { public void update(Namespace namespace, NodeRevisionDescriptors descriptors, NodeRevisionDescriptor descriptor, NodeRevisionContent content) throws IndexException; public void insert(Namespace namespace, NodeRevisionDescriptors descriptors, NodeRevisionDescriptor descriptor, NodeRevisionContent content) throws IndexException; public void delete(Namespace namespace, NodeRevisionDescriptors descriptors, NodeRevisionDescriptor descriptor, NodeRevisionContent content) throws IndexException; } public interface PropertyIndexer extends ExpressionFactory { public void update(Namespace namespace, NodeRevisionDescriptors descriptors, NodeRevisionDescriptor descriptor) throws IndexException; public void insert(Namespace namespace, NodeRevisionDescriptors descriptors, NodeRevisionDescriptor descriptor) throws IndexException; public void delete(Namespace namespace, NodeRevisionDescriptors descriptors, NodeRevisionDescriptor descriptor) throws IndexException; } The index exception would cause a rollback of the current transaction if the indexer was called within a transaction. If this exception is thrown in an asynchronous scenario the exception indicates that index and repository might be out of sync. I could implement some kind of configurable IndexTrigger that will call these interfaces if matching events occur (both contentType and URI-mapping). Should I? Daniel > > Regards, > Martin > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
