The uf parameter is used to specify which fields a user "may" query against - the "qf" parameter specifies the set of fields that an unfielded query term "must" be queried against. The user is free to specify fielded query terms, like "field1:term1 OR field2:term2". So, which use case are you really talking about.
Could you try to point to a real-world example of where your use case might apply, so we can relate to it? Generally, I would say that a Solr document/collection should have no more than "low hundreds" of fields. It's not that you absolutely can't have more or absolutely can't have 5,000 or more, but simply that you will be asking for trouble, for example, with the cost of comprehending and maintaining and communicating your solution with others, including this mailing list for support. What specifically pushed you to have documents with 1500 field? Also, is this 1500 fields that are always populated, or are there really a larger number of different record types, each with a relatively small number of fields populated in a particular document? -- Jack Krupansky On Wed, May 20, 2015 at 8:27 AM, Steven White <swhite4...@gmail.com> wrote: > Hi everyone, > > My solution requires that users in group-A can only search against a set of > fields-A and users in group-B can only search against a set of fields-B, > etc. There can be several groups, as many as 100 even more. To meet this > need, I build my search by passing in the list of fields via "qf". What > goes into "qf" can be large: as many as 1500 fields and each field name > averages 15 characters long, in effect the data passed via "qf" will be > over 20K characters. > > Given the above, beside the fact that a search for "apple" translating to a > 20K characters passing over the network, what else within Solr and Lucene I > should be worried about if any? Will I hit some kind of a limit? Will > each search now require more CPU cycles? Memory? Etc. > > If the network traffic becomes an issue, my alternative solution is to > create a /select handler for each group and in that handler list the fields > under "qf". > > I have considered creating pseudo-fields for each group and then use > copyField into that group. During search, I than can "qf" against that one > field. Unfortunately, this is not ideal for my solution because the fields > that go into each group dynamically change (at least once a month) and when > they do change, I have to re-index everything (this I have to avoid) to > sync that group-field. > > I'm using "qf" with edismax and my Solr version is 5.1. > > Thanks > > Steve >
