On Sun, Jan 25, 2009 at 2:05 PM, Gunaranjan Chandraraju < chandrar...@apple.com> wrote:
> Thanks > This sounds redundant to me - to store the fields separately and then > concat all of them to one copy field again. > Sometimes that may be the only way. For example, if you want to facet on some of those fields, as well as to search them all. > > My XML is like this > <address street="XYZ" state="CA" country="1" type="shipping" ...> > > I am currently using XPATH or XSL to separate them into individual indexed > fields like: address_state_1, address_type_1 etc. in SOLR. > > From what you say, it looks to me that I might as well just treat the > entire address as a single 'text field' and search within the text after > tokenizing. This way I don't need to have the _1, _2 as the single text > field will contain the information together (and thus grouped - so I know > which is shipping/billing etc?). Will there be any performance difference > between this and the copy field approach? > No I think, one field may even be better since you are creating less number of fields. If you never need to do faceting and you don't want to get the contents of each address field separately. This is your best option. > > Is there no other way (programmatic) to search across multiple fields? I > did take a quick look at dismax but again it needs the field names to be > specifically mentioned in the config file or in the query. I can't do this > as I am not able to predict the number of fields (e.g. credit cards a person > can have?). > > I like SOLR, but to me, this seems to be a very common and simple search > scenario/pattern - however its implementation in SOLR is appearing to be not > very straightforward. (My apologies, if I on the wrong track here because > I don't understand SOLR well. ) There had been some discussion on having wildcards in field names. But I guess nobody contributed (or had the need?) for the complete proposal. Copy Fields give a lot of flexibility which is what most people use. http://wiki.apache.org/solr/FieldAliasesAndGlobsInParams -- Regards, Shalin Shekhar Mangar.
