I only have a moment, but I can comment on both cases, at least a little. * Case 1 is very likely a variant of the problem fixed (superficially) in ab37336715cb7d84ed0c30b1cd2e9e6b85933774 and is not fixed in QP-proper, yet. The current workaround is "put filters and modifiers at the end". * Case 2 is something new to me. Could you pull the full query generated by the working and non-working versions out of your logs, per chance? If you're logging long-running queries longer than a second (not a bad idea, IMO), they're likely in there.
--miker On Wed, Nov 13, 2013 at 2:24 PM, Dan Wells <[email protected]> wrote: > Hello all, > > Having made the leap from 2.3 to 2.5, we have run into a few issues with the > updated query parser, and rather than dig into something I know from the > surface to be very complex, I am hoping someone might shed some light on > what is going on. The issues I am finding *seem* like bugs, but maybe I am > missing something fundamental in my queries. > > You see, we have an external system (SFX) which does automated queries of > the catalog to find book content. These queries are largely based on ISBN, > and when we upgraded to 2.5, they started to fail in strange ways. After > much poking and prodding, I have boiled things down to a couple simple cases > with surprising results. In both cases, the order of operands changes the > result set despite using what I think is a commutative operator (||). You > can test these queries using our current catalog, http://ulysses.calvin.edu/ > , but I can also take some time to find similar issues using Concerto > records if it comes to that. > > Case 1a: > item_form(s) && identifier|isbn:0830837035 || identifier|isbn:1844743829 (no > results) > vs. > identifier|isbn:1844743829 || identifier|isbn:0830837035 && item_form(s) (1 > result) > > In this case, I would have expected both to return 1 result. I also see the > same behavior even if the given ISBN is identical (a contrived example): > > Case 1b: > item_form(s) && identifier|isbn:0830837035 || identifier|isbn:0830837035 (no > results) > vs. > identifier|isbn:0830837035 || identifier|isbn:0830837035 && item_form(s) (1 > result) > > > > The next case is similar, but with slightly more nuance. I have two of the > same title, one print, one electronic. If I OR the ISBNs together, it > works: > > Case 2a: > identifier|isbn:074944990X || identifier|isbn:0749452897 -- WORKS > > identifier|isbn:0749452897 || identifier|isbn:074944990X – WORKS > > However, if I add a third ISBN to the mix, I now get different results > depending on the order of operands: > > Case2b: > identifier|isbn:074944990X || identifier|isbn:0749452897 || > identifier|isbn:7313054289 -- DOESN'T WORK (print result) > > identifier|isbn:074944990X || identifier|isbn:7313054289 || > identifier|isbn:0749452897 -- DOESN'T WORK (print result) > > identifier|isbn:7313054289 || identifier|isbn:074944990X || > identifier|isbn:0749452897 -- DOESN'T WORK (no results) > > identifier|isbn:7313054289 || identifier|isbn:0749452897 || > identifier|isbn:074944990X -- DOESN'T WORK (no results) > > identifier|isbn:0749452897 || identifier|isbn:074944990X || > identifier|isbn:7313054289 -- DOESN'T WORK (e result) > > identifier|isbn:0749452897 || identifier|isbn:7313054289 || > identifier|isbn:074944990X -- DOESN'T WORK (e result) > > I do seem to get the same behavior when using a more compact query notation > (which I believe should be identical in effect): > > Case 2c: > identifier|isbn:(074944990X || 0749452897) -- WORKS > > identifier|isbn:(074944990X || 0749452897 || 7313054289) -- DOESN'T WORK > (print result) > > identifier|isbn:(0749452897 || 074944990X || 7313054289) -- DOESN'T WORK (e > result) > > > > Based on when development in query parsing was most active, I imagine this > behavior has existed since 2.4. Can anyone verify that? Also, is there an > explanation for this behavior which I may be missing? If not, can anyone > more familiar with this code at least narrow down what is causing these > issues? I’m willing to dive in if necessary, but given the complexity of > this code, I may not soon have enough free time to effectively troubleshoot > this. > > Finally, I am happy to move the conversation over to LP if that is a better > venue, but I was struggling with pinpointing exactly what this bug affects > (and therefore how to file it properly), so I thought I would first seek > input from the list. > > Thanks, > Dan > > > Daniel Wells > Library Programmer/Analyst > Hekman Library, Calvin College > 616.526.7133 > > > -- Mike Rylander | Director of Research and Development | Equinox Software, Inc. / Your Library's Guide to Open Source | phone: 1-877-OPEN-ILS (673-6457) | email: [email protected] | web: http://www.esilibrary.com
