Hi, I'm sorry I had not the time yet to have a close look to your patch, I will do that soon. AFAIK Lucene is a tool for full text search, so it is perfect for an implementation of the <contains> operator (which currently is really really slow). Properties are table oriented, so a perfect candidate for an SQL based search (or XQuery, if an XML store is used). It is possible to use different implementations for different operators, so you may have a lucene based implementation for <contains> and any other implementation for the property based operators.
I hope I can spend some time for implementing DASL for JDBC based stores starting end of January. Regards, Martin -----Original Message----- From: LOMBART Christophe [mailto:[EMAIL PROTECTED] Sent: Freitag, 16. Januar 2004 13:25 To: Slide Developers Mailing List Subject: RE: Proposal : index store - Lucene >To have this query stuff really useful we need fast and scalable >searching of properties. I thought Stefano proposed to unconditionally >use an RDBMS for this purpose. I'd say this is one way to go, but it >still would be nice to have a Lucene solution. There was this Lucene >thread in this list mainly by Stefano and Erik. Have a look at it... I think both solution can be supported depending on the application needs. >> * Integration with the current Search features ? How did you see that ? >I hope Martin Wallmer can say something on this particular topic. But >isn't public SearchQueryResult search(String parentUri, SearchQuery >query) the right place to do the connection? Currently, I'm using an IndexHelper class which make some method calls in an "IndexStore". IndexStore was an old interface made by Remy. So I simply add this interface in the AbstractStore and implement it. Next week, I will check how to integrate my code with what Martin did. >Not sure if I understand you correctly. Do you think of the problem >people should not be allowed to search over content they do not have >access to? Yes >If so, I'd propose to do it the other way round. Index and >search over all documents, but filter the result using authentication >info. This would be fast, wouldn't it? Yes, I agree with this solution. I'm just wondering if it will be fast. I will test it with an important Slide domain >I do not quite understand why you use interceptors here. Why don't you >just augment AbstractStore/ExtendedStore to call the configured >IndexStore as well? This would be in storeObject, commit, etc. Correct - I'm stupid :-) Certainly, one bad reason was to avoid some modification in the core classes but anyway it is required. Thanks for this mail, Christophe --------------------------------------------------------------------- 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]
