Hi Martin, I'd like to do some work on the indexer framework if appreciated. My favorit approach (as mentioned before) is to trigger the indexer by events, not to let the stores call them directly. This has several advantages: - There can be multiple indexers called when a single resource is stored. This could be useful if you want to enable different queries on the resource (e.g. xpath or full text queries). The selection of which indexer to use could be done by uri-mapping or by content-type. - The event collections could be used to avoid unnecessary indexing (e.g. if create and delete was called in one transaction) - No changes are needed in Namespace or ParentStore, this would avoid bloating up this central classes.
I'm thinking of an index trigger that implements the event listener interface. The trigger will call methods on the two indexer interfaces that we'll need: ContentIndexer and PropertyIndexer (or something like that). If appreciated I could implement these things and send a proposal so that you can have a look at this. Daniel 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. > > 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]
