Thanks for the response. Yes, the queries are fairly large. Basically, the corporate security policy dictates that we use row-level security attributes from the DB for access control to Solr. So, we bake row-level security attributes from the database into the index, and then, at query time, ask for those same attributes from the DB and pass them as part of the Solr query. So, imagine a bank VP with access to tens of thousands of customer records and transactions, and all those access attributes get sent to Solr. The system works well for the low-level account managers and low-entitlement users, but cannot scale for the high-level folks.
POSTing the data appears to avoid the header threshold issue, but it breaks because of the "too many boolean clauses" error. gearond wrote: > > Probably you could do it, and solving a problem in business supersedes > 'rightness' concerns, much to the dismay of geeks and 'those who like > rightness > and say the word "Neemph!" '. > > > the not rightness about this is that: > POST, PUT, DELETE are assumed to make changes to the URL's backend. > GET is assumed NOT to make changes. > > So if your POST does not make a change . . . it breaks convention. But if > it > solves the problem . . . :-) > > Another way would be to GET with a 'query file' location, and then have > the > server fetch that query and execute it. > > Boy!!! I'd love to see one of your queries!!! You must have a few ANDs/ORs > in > them :-) > > Dennis Gearon > -- View this message in context: http://lucene.472066.n3.nabble.com/GET-or-POST-for-large-queries-tp2521700p2526934.html Sent from the Solr - User mailing list archive at Nabble.com.
