As it turns out I'm back to GET myself. I just noticed that tomcat as well, although ultimately plan to run under weblogic (not sure what the length on that url is and/or if there are limits on the flex client doing the GET)
Reading the book (page 108) I noticed that my querys need to have more fq=field:value params. Earlier I had incorrectly defined a single fq param with a bunch of criteria such as fq=field_1:value AND field_2:value_2 AND (role:r1 or role:r2 or role:r3 or role:r3) Apparently the boolean role clause can be speficied as: fq=role:(r1 || r2 || r3 || r4) as opposed to: ... AND (role:r1 or role:r2 or role:r3 or role:r3) That syntax shortens queries too. Note I havent' tested yet against a smaller set of docs to be sure the new query syntax works... -----Original Message----- From: markwaddle [mailto:m...@markwaddle.com] Sent: Monday, October 26, 2009 2:12 AM To: solr-user@lucene.apache.org Subject: RE: Solr under tomcat - UTF-8 issue I was originally using POST for the same reason, however I discovered that Tomcat could easily be configured to accept any length URI. All it requires is specifying the maxHttpHeaderSize attribute in your default Connector in server.xml. I set my value to 1MB, which is certainly excessive, but it ensures I will never hit the limit. As the other chap mentioned, I now have the benefits of caching and most importantly, proper web logs! I also have a similar situation where I constrain the search results based on the user's role. I have only two roles to support, so my case is very simple, but I could imagine having a multivalued "role" field that you could perform facet queries on. Mark Glock, Thomas wrote: > > Thanks - > > I agree. However my application requires results be trimmed to users > based on roles. The roles are repeating values on the documents. > Users have many different role combinations as do documents. > I recognize this is going to hamper caching - but using a GET will > tend to limit the size of search phrases when combined with the > boolean role clause. And I am concerned with hitting url limits. > > At any rate I solved it thanks to Yonik's recommendation. > > My flex client httpservice by default only sets the content-type > request header to "application/x-www-form-urlencoded" what it needed > to do for tomcat is set the content-type request header to > content-type = "application/x-www-form-urlencoded; charset=UTF-8"; > > If you have any suggestions regarding limiting results based on user > and document role permutations - I'm all ears. I've been to the > Search Summit in NYC and no vendor could even seem to grasp the concept. > > The problem case statement is this - I have users globally who need > to search for content tailored to them. Users searching for 'Holiday' > don't get any value from 10000 documents having the word holiday. What > they need are documents authored for that population. The documents > have the associated role information as metadata and therefore users > will get only the documents they have access to and are relevant to > them. That's the plan anyway! > > By chance I stumbled in Solr a month or so ago and I think its > awesome. I got the book two days ago too - fantastic! > > Thanks again, > Tom > -- View this message in context: http://www.nabble.com/Solr-under-tomcat---UTF-8-issue-tp26040052p2605494 2.html Sent from the Solr - User mailing list archive at Nabble.com.
