Hi Martin,
there are some things left to do on event driven index triggering (enable 
synchronous or asynchronous index updating).
As I mentioned before the indexers can be implemented using the singleton 
patter  ( .getInstance()  ), so in real world an indexer might look like this

public class LuceneIndexer implements Indexer, IBasicExpressionFactoryProvider 
{
        private static LuceneIndexer indexer = new LuceneIndexer();

        private LuceneIndexer() {}

        public LuceneIndexer getInstance() {
                return indexer;
        }

        /* ... impl of interface methods ...*/
}

I don't know exactly how to access the different indexers via DASL. There must 
be some way to tell slide which index to use if basicsearch is used.
My suggestion would be to use the SEARCH-method request url to select the 
indexer to use if basicsearch is used.

Example:
Domain.xml is used to configure some indexers (a combination of content and 
property-indexer).
<indexer-mappings>
        <indexer-mapping uri="/indexer/fileBasedIndexer" 
content-indexer="org.apache.slide.search.LuceneIndexer" 
property-indexer="org.apache.slide.search.GenericPropertyIndexer" />
        <indexer-mapping uri="/indexer/fastIndexer" 
content-indexer="org.apache.slide.search.LuceneIndexer" 
property-indexer="org.apache.slide.search.DBPropertyIndexer" />
...
</indexer-mappings>

The url of the search request will be used, to select the indexer-mapping that 
will be used for the query. If there is only one indexer-mapping registered, 
the url is ignored.

SEARCH /indexer/fastIndexer HTTP/1.1
Host: example.org
Content-Type: application/xml
Content-Length: xxx

<d:searchrequest xmlns:d="DAV:">
  <d:basicsearch>
    <d:select>
      <d:prop><d:getcontentlength/></d:prop>
    </d:select>
    <d:from>
      <d:scope>
        <d:href>/container1/</d:href>
        <d:depth>infinity</d:depth>
      </d:scope>
    </d:from>
    <d:where>
      <d:gt> 
        <d:prop><d:getcontentlength/></d:prop>
        <d:literal>10000</d:literal>
      </d:gt>
    </d:where>
      <d:orderby>
        <d:order>
        <d:prop><d:getcontentlength/></d:prop>
        <d:ascending/>
      </d:order>
    </d:orderby>
  </d:basicsearch>
</d:searchrequest>

If all indexers would be registered by using the index trigger, we can use 
symbolic names to let the mapping configuration look much nicer.
What do you think?
Regards,
Daniel



Am Mittwoch, 25. Februar 2004 14:06 schrieb [EMAIL PROTECTED]:
> Hi Daniel,
>
> that looks good! I like, that you can either use contenttype mapping or
> uri mapping, as Stefano suggested. Now how to access with DASL?
>
> Regards,
> Martin
>
> > -----Original Message-----
> > From: Daniel Florey [mailto:[EMAIL PROTECTED]
> > Sent: Mittwoch, 25. Februar 2004 14:07
> > To: Apache Slide Slide
> > Subject: Event driven indexing
> >
> >
> > Hi,
> > just checked in the event driven index trigger.
> > It can trigger indexers that implement the Indexer interface. The
> > configuration of indexers is the same as for the extractor
> > framework. I've
> > implemented a simple LoggingIndexer that logs a message every
> > time the index
> > should be updated, created or dropped. This is a good
> > starting point for
> > custom implementations.
> > Indexer matching can be achieved via uri or content-type mapping (see
> > extractor)
> >
> > Notes:
> > * The current namespace can be accessed via the given uri.
> > * The index trigger relies on the event collectors, so they
> > must be activated.
> >
> > This is the part of the configuration in Domain.xml that
> > activated the index
> > trigger.
> > The custom indexers can be configured via Configurable
> > interface (see my
> > extractor posing for an example). Indexers and extractors can
> > follow the
> > singleton pattern if they should be accessable inside the vm.
> >
> > <listener classname="org.apache.slide.search.IndexTrigger">
> >      <configuration>
> >          <indexer classname="org.apache.slide.search.LoggingIndexer"
> > uri="/files/articles" />
> >      </configuration>
> > </listener>
> >
> > Regards,
> > Daniel
> >
> > ---------------------------------------------------------------------
> > 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]


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to