Hi,
see below
Am Mittwoch, 4. Februar 2004 10:59 schrieb Wallmer, Martin:
> Hi Christophe,
>
> > -----Original Message-----
> > From: Christophe [mailto:[EMAIL PROTECTED]
> > Sent: Dienstag, 3. Februar 2004 21:53
> > To: Slide Developers Mailing List
> > Subject: Re: proposal: integrate indexing - search
> >
> > Wallmer, Martin wrote:
> > >Hi,
> > >
> > >I just checked in a proposal for integrate indexing and
> >
> > search, jakarta-slide/proposals/indexing (as openOffice and pdf).
> >
> > >Christophe, Nick, would that architecture allow you to
> >
> > integrate your implementation?
> >
> > For me, it is ok. In fact, I stopped my implementation in order to be
> > sure to follow the same ideas. So, that's good for me to
> > rewrite some part.
> >
> > If I understand, new code is needed for :
> > * For the search service :
> > * JDBC implementation for the search service. Anyway we can
> > still used the current generic implementation.
> > * Give more flexibility in the search service in order to
> > support all scenarios mentionned in your proposal.
>
> a little bit redesign is necessary.
>
> > * An indexer for content and/or properties. I have one in my proposal
> > based on the existing interface
> > "org.apache.slide.store.IndexStore". I
> > can make some clean-up. After a lucene implementation can be started.
> > * Modify the ParentStore in order to call the indexer. My
> > proposal used
> > an index helper but you are right, it is better to do it in a
> > Store like
> > ParentStore.
> >
> > Is it correct ? Martin, do you plan to start this new stuff in short
> > term ? Do you need some help ?
>
> My next steps are modifying Namespace (to configure an Indexer), the
> ParentStore (to call the configured Indexer). I'll check that in the next
> days. After that a real implementation could be started. If you'd like to
> volonteer :-). IndexStore needs to be extended somehow by the
> ExpressionFactory (I don't like that name anymore, isn't that in fact is
> the ExpressionCompiler?), that should be my work next week.
I've implemented an event collection listener that can trigger the indexers.
The indexers can be configured via Configurable interface. They can be
configured in the following manner:
<events>
<!-- needed if you want to trigger transaction aware indexer -->
<listener classname="org.apache.slide.event.VetoableEventCollector" />
<!-- needed if you want to trigger asynchronous indexers that are not
transaction aware -->
<listener classname="org.apache.slide.event.TransientEventCollector"
/>
<!-- This is the trigger itself. It can trigger indexers by matching uri
substrings or content-type -->
<listener classname="org.apache.slide.index.IndexTrigger">
<configuration>
<!-- Dummy indexer that implements ContentIndexer and PropertyIndexer
and
logs every indexing request (only for resources under /files/test) -->
<indexer classname="org.apache.slide.index.LoggingIndexer"
uri="/files/test" />
<!-- Dummy indexer that implements ContentIndexer and PropertyIndexer
and
logs every indexing request (for all resources of type text/xml) -->
<indexer classname="org.apache.slide.index.LoggingIndexer"
content-type="text/xml" />
<!-- Dummy indexer that implements ContentIndexer and PropertyIndexer
and
logs every indexing request (for all resources of type text/xml und
/files/test) -->
<indexer classname="org.apache.slide.index.LoggingIndexer"
content-type="text/xml" uri="/files/test" />
<!-- This might be the configuration for an rdbms indexer. Can be
configured
to map properties to db types/columns -->
<indexer classname="org.apache.slide.index.LoggingIndexer"
content-type="text/xml" uri="/files/test">
<configuration>
<property-mapping name="d:getlastmodified"
type="date"/>
<property-mapping name="d:getcontentlength"
type="long" />
</configuration>
</indexer>
</configuration>
</listener>
</events>
I can send a patch (even if this was just because I wanted to get things clear
in my mind). But it only works if events are enabled...
Regard,
Daniel
>
> JDBC search should be the next step. I don't have a feeling how much work
> this will be, as I don't know that implementation (and table design) yet.
> If anybody could provide sample SQL statements for different DASL queries,
> using AND, OR, NOT, ORDER BY, LIMIT and stuff like this, retrieving the
> resource ids (uri), this would help.
>
> > Last point, what about the properties to display for a search result.
> > Sometime, it should be interesting to have a simple list of content
> > references with only a subset of the document proporties.
> > So, the search service can also optimize the way of building the
> > properties to used (eg. for a JDBC implementation, the select
> > part of a
> > sql statment).
>
> You're right. The current implementation gets the resource id's of the
> requested resources, loads them, and then the requested properties are
> delivered with the response. The reason for that was flexibility (can be
> used by any search implementation), and the way computed properties are
> handled. With the current approach the search engine does not have to worry
> about.
>
> Yes, this can be optimized.
>
>
> 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]
