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]
