Hi, currently I'm putting together all the things discussed in the last weeks (thanks a lot to all of you) and design an index - search framework. It won't go far away from what already exists or was discussed yet. I still not know exactly, how to integrate Stefano's ideas, but I have the feeling, we are not too far apart :-).
I did not start yet with JDBC store search. It will mainly be a new implementation of IBasicExpressionFactory. Regards, Martin > -----Original Message----- > From: Christophe [mailto:[EMAIL PROTECTED] > Sent: Donnerstag, 29. Januar 2004 00:35 > To: Slide Developers Mailing List > Subject: Re: Integrate Indexstore and SEARCH (was Indexing store) > > > Now, I reviewed the search service provided by Martin. Good ! > that was > the first point to start in order to integrate the search > service and an > indexstore :-) > With this stuff in mind, I have some questions : > * Martin, Did you already start an specific implementation for a > J2EE/JDBC store ? if not, how do you see that ? Just a new > descendant of > BasicQuery and/or a specific implementation for > IBasicExpressionFactory ? > * Nick, if I understand you start something also into this > direction - > correct ? I have not your code, can you send me this one ? > > Thanks, > Christophe > > > > Nick Reddel wrote: > > > > > > >>>-----Original Message----- > >>>From: Christophe > [mailto:[EMAIL PROTECTED] > >>>Sent: Monday, January 26, 2004 9:22 PM > >>>To: Slide Developers Mailing List > >>>Subject: Re: Integrate Indexstore and SEARCH (was Indexing store) > >>> > >>> > >>>Wallmer, Martin wrote: > >>> > >>> > >>> > >>>> > >>>> > >>>> > >>>> > >>>>>-----Original Message----- > >>>>>From: Nick Reddel [mailto:[EMAIL PROTECTED] > >>>>>Sent: Freitag, 23. Januar 2004 13:31 > >>>>>To: 'Slide Developers Mailing List' > >>>>>Subject: Re: Integrate Indexstore and SEARCH (was Indexing store) > >>>>> > >>>>> > >>>>> > >>>>> > >>>>>Hi Christophe > >>>>> > >>>>>It looks like our solutions should fit together - I went > >>>>> > >>>>> > >>>ahead and did > >>> > >>> > >>>>>the indexing and search implementations, on the meta-data, > >>>>> > >>>>> > >>>while you > >>> > >>> > >>>>>went with the higher-level api, mostly focussed on the content. > >>>>> > >>>>>Some things: > >>>>>-- For some applications (e.g. mine), it's critical that > >>>>>indexing occur > >>>>>within the transaction [i.e. SEARCH needs to reflect the > >>>>> > >>>>> > >>>exact store > >>> > >>> > >>>>>state). A flag to indicate synchronous indexing? > >>>>> > >>>>> > >>>>> > >>>>> > >>>>Good point! Do you think its enough when the indexer takes > >>>> > >>>> > >>>part at the > >>> > >>> > >>>>two > >>>>phase commit? > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>In my previous proposal, I send a collection of all modified > >>>revisiondescriptors and revisioncontents to the indexer at > >>>the end of > >>>a transaction. > >>>I suppose the best place to call the indexer is > >>>NamespaceAccessTokenImpl.commit() - correct ? > >>> > >>> > >>> > >>>>>-- Property typing is a must, I think. At least to be able > >>>>> > >>>>> > >>>to pull out > >>> > >>> > >>>>>meaningful date-ordering, etc. I've got two (one rdbms, one non) > >>>>>solutions in mind - I'll run them by you. > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>Nick , I don't understand, can you explain ? > >>> > >>> > > > >OK. Webdav resource properties are not just text.For a > search criteria > >like the following: > > <d:where> > > <d:gt> > > <d:prop> > > <d:getcontentmodified/> > > </d:prop> > > <d:literal>2004-01-13 15:27:05:064 CET</d:literal> > > </d:gt> > > </d:where> > > > >to be processed effectively, both the indexer and the query > engine need > >to know that > >d:getcontentmodified should be indexed and queried as a date, not as > >text. > > > >So how to pass the property type information to the indexer and query > >engine? If you�re using properties seriously, you may end up with a > >long, long block in Domain.xml of the following: > > > ><meta-types xmlns:d="DAV:" > xmlns:s="http://jakarta.apache.org/slide/";> > > <type qname="d:getlastmodified" > >java-class="java.util.Date"/> > > <type qname="d:getcontentlength" > >java-class="java.lang.Long"/> > > <type qname="s:lastmodified" > >java-class="java.util.Date"/> > > > >...but it�s better than nothing I guess. I'd prefer to extract type > >information from XML schema, but that would require either > the non-api > >schema information sections of Xerxes, or XMLBeans, or similar. > > > > > >Nick > > > > > >--------------------------------------------------------------------- > >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]
