Hello again, Thank you for your replies!
Is the only difference between the propertiesindexer and contentindexer that the former has an expression factory which can deal with all expressions? Or do I need to register as both to use the same index for <DAV:contains>? About the ACLs: Where does this scanning happen? I've browsed the source to no avail... Also: ACLs are cached, right? So looping over all of them is not really costly, is it? However, I am a bit concerned about big result sets, which may just occur if you search some something common (like computer in a computer newspaper archive). Maybe, a more optimal ACL store is required for this situation. We thought a little bit about it here and came up with the idea of using Lucene for it. If we just store the nodes in the document/dir tree which actually have non-inherited ACLs in an index, we could query it in such a way to efficiently find out the presence of ACLs somewhere up in the hierarchy that refer to a certain action and a certain user/role. For example: Store the uri of the node and per action two fields: action-deny and action-grant. These fields would store the users and roles for which the action is granted or denied. I am not sure how to introduce the user/roles heirarchy here, though... However, for plain searching, only the 'read' action is needed, right? So this model would get much simpler and maybe more managable. What do you think about this? Best regards, Max Pfingsthorn Hippo Oosteinde 11 1017WT Amsterdam The Netherlands Tel +31 (0)20 5224466 ------------------------------------------------------------- [EMAIL PROTECTED] / www.hippo.nl -------------------------------------------------------------- -----Original Message----- From: Stefan L�tzkendorf [mailto:[EMAIL PROTECTED] Sent: Thursday, May 19, 2005 10:07 To: Slide Developers Mailing List Subject: Re: lucene dasl evaluation Hello Max, an implementation of IndexStore has a getBasicExpressionFactory(). Depending on how the index store is registered (as propertiesindexer or contentindexer) the index store the expression factory must be able to handle the <DAV:contains> expression for content or all the other for properties searching. The LuceneExpressionFactory (in 2.2) translates dasl basicsearch queries to lucene expressions. But consider that the translation is done with respect to the structure of the lucene index that the LuceneContentIndexer/LucenePropertiesIndexer creates, i.e. how property names are mapped to lucene fields etc. So if you are using LuceneContentIndexer/LucenePropertiesIndexer or equivaliant to create the index you can use LuceneExpressionFactory, otherwise I think you have to write your own expression factory and return it from your index store implementation. Regarding the ACL evaluation there is no progress. In 2.2 the result of a lucene based query (and other queries to) is scanned sequentially, and for each resource found, the permissions are checked. The problem with Lucene filters will be, to calculate an independend data structure (to transform it to a bit set) that represents the permissions in your namespace. If youo have any ideas on this field, I'm really interested to hear about. Regards, Stefan Max Pfingsthorn wrote: > Hello Devs, > > I am very interested in the new meta-data search using lucene in 2.2. In our > production environment, we have one slide instance serve 10+ namespaces, some > counting more than 100.000 documents, all using the JDBCStore. Unfortunately, > the DASL searches take a long time on these contexts (especially using > <d:contains>), while a lucene search alone would be much faster. Since we use > slide 2.1-final in our environment and 2.2 is not mature enough for us, I > would like to use the new search implementation in our 2.1 installation. > > We already have our custom IndexStore implementation, so my question is where > to hook up the LuceneExpressionFactory. I am generally a bit lost on how > exactly the IBasicExpressionFactory instance is obtained during the > evaluation of the SearchMethod and IBasicQueryImpl. Is it enough if our > IndexStore implementation returns a LuceneExpressionFactory instead of a > TextContainsExpressionFactory? Any tips would be highly appreciated. > > Another problem of us are the ACLs and their evaluation while searching. Is > there any progress on this? I was thinking that a lucene implementation may > use Filters > (http://lucene.apache.org/java/docs/api/org/apache/lucene/search/Filter.html) > representing the user's effective privilege set (mainly 'read', I guess) on > all documents, which may be cached and therefore quite efficient. Any ideas? > > Thanks in advance for your help! > > Best regards, > > Max Pfingsthorn > > Hippo > > Oosteinde 11 > 1017WT Amsterdam > The Netherlands > Tel +31 (0)20 5224466 > ------------------------------------------------------------- > [EMAIL PROTECTED] / www.hippo.nl > -------------------------------------------------------------- > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > -- Stefan L�tzkendorf -- [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]
