On Sat, Apr 4, 2009 at 3:43 PM, Wojtek Janiszewski <[email protected]> wrote: > Hi, > thanks for your input. Please see my comments inline. > > Wojtek > > Adriano Crestani: >> >> Hi Wojtek, >> >> Some comments inline: >> >> > Found elements would be stored with current document data. >> >> I don't see any reason for storing the entire document content in the >> index, why would you do that? Couldn't you just store some URI that would >> point to the original file? > > I was trying to say here that found elements should be remembered. We > wouldn't store anything but references to them. > >> >> *> All* | All above fields to provide non-filter queries. >> >> You don't need to do it, if you do, you will basically duplicate the >> posting list size in the index. To reproduce what you want, the field "all" >> should be available only for querying purposes, for example, the user could >> type 'all:store' in the query, and before processing the query it could be >> expanded to all the "searchable" fields: component:store >> contribution:store...etc. It's a common practice on unstructured data world, >> it's so common that Lucene has a query parser for that called >> MultiFieldQueryParser : )...I think you already said it here: >> >> > none (all document fields would be used to search) >> >> > regular expressions > > Yes, this is probably what I wanted to achieve :) > >> Can you give me some example of regular expressions? > > I mean queries enhaned by regex syntax, ie. "Component[A-C]\.component" to > find everywhere components from A to C. > I plan to use here RegexQuery instead one of QueryParsers and as I see > regular expressions cannot be used in standard Lucene syntax, so those > searches wouldn't be as powerfull as standard ones. I mean you won't use > logic operators and multiple fields and etc., it would be limited only to > one or all fields and regex query string. > >> >> I liked your presentation idea : ) >> >> Architectural outline session is also very complete : ) >> >> Good luck ; ) >> >> Adriano Crestani > >
Hi Wojtek Nice proposal (and something that would be really useful for Tuscany). A question. It feels like absolutely the right thing to do to start at the contribution and contribution content level but I'm interested in the index field you have described as "Service/Reference/Component/Binding/Implementation/... " which to me suggests some indexing of the contents of the files in the contribution, in this case the composite file. I'm asking as I'm attracted by the presentation example you give where you show an initial phrase search giving way to more targeted item based searches. A complexity of Tuscany is that it's based on number hierarchies and relationships, e.g. contribution import/export component type component promotion component wiring domain/node confguration intent and policy configuration Finding things can often mean searching through various, seemingly unrelated, files. This is particularly the case where policy is concerned. It seems that you are solving this problem and I'm wondering what general provision can be made to extend the index beyond the original contribution object. Regards Simon
