PPS: One answer I’ve gotten from solr-ites is basically “Well, yeah, AND/OR aren’t really boolean operators to these query parsers, they are just indication of lucene optional/required clauses.”

To which my answer is: “Okay, but then why use syntax that looks like boolean algebra, and that makes it very hard to predict exactly how they are translated to optional/required clauses, to the novice. Why not use a different syntax that actually indicates what it’s doing?” Perhaps the answer is “Well, becuase users are used to AND/OR”, but I think it’s no service to give users a syntax they are used to but with semantics that they are NOT used to!

However, it’s possible that if you keep in mind “translating to lucene optional/mandatory clauses”, it will be the right mental model to figure out why the query parsers are doing what they’re doing. Although I still can’t figure it out, especially for some of the especially weird cases where terms are dropped altogether.

Instead, I actually parse all user queries in my own application, and then construct Solr queries (using a ‘lucene’ type query, with nested dismax type queries) that I know do what is needed for the user query to be interpreted with more typical boolean logic.

Of course, it’s possible I’ve gotten it wrong too, but theoretically my parser/interpreter can then be fixed to what I want.

Now, it might make even MORE sense to do this as an actual custom Solr query parser, but I lack the Solr/java comfort/skills to do that, so I’d rather do it in ruby. I think it would probably in some ways be better to do this in Java as a Solr plug-in query parser, rather than at the application layer, but oh well.

Here’s the specs from my code that show how various user-entered queries are translated to Solr. Note they also take care of various types of “pure negative” queries that lucene and dismax query parsers can’t handle ‘right’ either (I think edismax fixes some but not all of these ‘pure negative’ cases). Hopefully the spec file is somewhat readable, despite (or because of!) the helper functions I put in to test generated solr query params against templates.

https://github.com/projectblacklight/blacklight_advanced_search/blob/master/spec/parsing_nesting/to_solr_spec.rb

raise StandardError.new

“raise StandardError” does the same thing, it’s just a shortcut. And:

raise StandardError, “message” ==== raise StandardError.new(“message”)

I don’t know the way to avoid backtrace generation when throwing an actually explicitly created Exception object, but there probably is one.

Note: raise/rescue DO correspond to JAVA’s throw/catch. ruby’s throw/catch is something different: It can only be used in ‘static scoped’ situations, basically where the catch is in a static code block that’s a parent of the throw. But if people are using raise/rescue for ‘flow control’ scenarios in places where throw/catch would work…. would be interesting to benchmark the performance of throw/catch. throw/catch at least is indeed actually intended for flow control.

Maybe nobody uses em cause they smell suspiciosuly like the dreaded ‘goto’, but that’s essentially what you’re doing with raise/rescue if you’re using em for flow control too, and apparently that doesn’t stop some people? Very curious what code you saw that was using raise/rescue like this, it’s certainly not a recommended thing to do by anyone (I don’t think?).

Sadly UKMARC was abandoned about ten years ago because it was just so unsatisfactory trying to convert from USMARC to UKMARC. It’s always easier to convert metadata into a format which is less expressive, so we all moved to USMARC instead.