Re: Integrate Indexstore and SEARCH (was Indexing store)

[Christophe]

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]