Hi, > -----Original Message----- > From: Oliver Zeigermann [mailto:[EMAIL PROTECTED] > Sent: Donnerstag, 22. Januar 2004 10:13 > To: Slide Developers Mailing List > Subject: Re: Integrate Indexstore and SEARCH (was Indexing store) > > > Christophe wrote: > >> In Domain.xml we could have something like: > >> > >> <store name="jdbc" classname="org.apache.slide.store.BindingStore"> > >> <nodestore > classname="org.apache.slide.store.impl.rdbms.JDBCStore"> > >> <parameter name="driver">com.mysql.jdbc.Driver</parameter> > >> <parameter > >> > name="url">jdbc:mysql://localhost:3306/test?autoReconnect=true > </parameter> > >> > >> <parameter name="user">wam</parameter> > >> <parameter name="password"/> > >> <parameter > >> > name="adapter">org.apache.slide.store.impl.rdbms.MySqlRDBMSAda > pter</parameter> > >> > >> </nodestore> > >> <securitystore> > >> <reference store="nodestore"/> > >> </securitystore> > >> <lockstore> > >> <reference store="nodestore"/> > >> </lockstore> > >> <revisiondescriptorsstore> > >> <reference store="nodestore"/> > >> </revisiondescriptorsstore> > >> <revisiondescriptorstore> > >> <reference store="nodestore"/> > >> </revisiondescriptorstore> > >> <contentstore > >> classname="org.apache.slide.store.txfile.TxFileContentStore"> > >> <parameter name="rootpath">mysql/store/content</parameter> > >> <parameter name="workpath">mysql/work/content</parameter> > >> </contentstore> > >> <indexer classname="my.lucene.Indexer"/> > >> <searchengine> > >> <parameter > name="propertySearchClass">my.sql.SearchEngine</parameter> > >> <parameter > >> name="ContentSearchClass">my.Lucene.SearchEngine</parameter> > >> </searchengine> > >> </store> > >> > >> Does this make sense? > >> > >> > >> > > Good. So, let's start with that no ? > > I agree it makes sense to configure different indexers and search > engines per scope, but I do not see why this has to be done and > restricted to the normal store definition. I could imagine a szenario > where I have part of my flat text resources in the file system and my > XML text resources in, say, Tamino. It might make sense to have a > *single* full text index for both stores in order not to have two > queries and to merge search results. >
If you want to have a structure for example foo/xmlData foo/textData where content data stored into xmlData goes into Tamino, textData to filesystem, it would make more sense to define a store for foo/xmlData AND for foo/textData with a search engine associated to each of them. If you now make a SEARCH on foo or below for all resources containing "otto", both search engines are called, result is merged. This is done by org.apache.slide.search.basic.BasicQueryEnvelope. Next scenario: if you have a store mapped on foo/ and you want to have the content of foo/my.xml go into Tamino, and the content of foo/my.txt to filesystem (indexed by lucene), your store implementation (content and index) must manage that. Also the search engine for that scope must manage this situation. I still have the feeling, that search engine (consisting of prop and content search) and store (as defined in domain.xml) is a 1:1 relation. > This also raises the question where should Lucene indexes > reside? In the > normal file system? If so it would be hard to include them in > transactions. Maybe it makes sense to have them as part of an > ordinary > store.... Hmmm, not really... > > Oliver > > > --------------------------------------------------------------------- > 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]
