Dan Scott (very) recently made a great improvement to our SRU-to-search code by converting the hard-coded index definition map to use the actual configuration data available in 2.0+. First, thanks, Dan, for taking it the last mile!
On that front, there's some more we can do. Dan and I have discussed in IRC a couple of these things, particularly relaxing the alias inclusion and adding in some static filters and modifiers as index axes. Here's a list of those static filters which we have: * available -- actually a modifier, but can be spelled: available:true * ascending, descending -- adjusts sort order, actually a modifier, but can be spelled: descending:true * metarecord, metabib -- causes a metarecord (instead of direct record) search, actually a modifier, but can be spelled: metarecord:true * sort -- takes the sort axis (more on that later) * format -- a backward-compat option for item_form and item_type * before, after, during, between -- special filters that use the date1 and date2 data in MARC * statuses -- a list of the status ids we care about for item visibility record inclusion * locations -- a list of the shelving locations we care about for item visibility record inclusion * site -- the shortname or id of the org unit we want to search * depth -- the numeric depth (actor.org_unit_type.depth) that provides scope to "site" * lasso -- the id of a lasso (org unit group) to search * my_lasso -- the id of a user-defined lasso. supported by the syntax, but not yet by the search code * offset -- result set offset * limit -- result set limit * superpage -- the search superpage for this query * superpage_size -- the size of superpages * check_limit -- max number of records to check for visibility (superpage * superpage_size) * core_limit -- number of record to return for checking (usually the same as check_limit) * skip_check -- number of records to ignore at the front of the query for visibility checking (approx: (superpage - 1) * superpage_size) * estimation_strategy -- (see comment in opensrf.xml.example from EG source) * preferred_language -- add language bonus if the record matches this * preferred_language_weight, preferred_language_multiplier -- language match bonus to supply (multiplier, as the name suggests) Not all of these need to be (or, necessarily should be) supported directly by the explain doc, but some should. My rough guess would be: available, ascending, descending, sort, format, before, after, statuses, locations, site, depth, lasso, offset, limit, preferred_language, preferred_language_weight and preferred_language_multiplier. Now, why haven't I mentioned things like the valid values for sort axis, or things like audience() and item_form() filters? Because they are now covered by the SVF topic branch's configuration, and can be pulled in in the same way that search classes, fields and aliases are (though we're only using aliases today, which for SRU seems correct to me). So this can be considered a sly way of opening the "Mike wants to merge in SVF now" discussion. Thoughts or comments on either the hard-coded filters stuff or SVF merge? -- Mike Rylander | VP, Research and Design | Equinox Software, Inc. / Your Library's Guide to Open Source | phone: 1-877-OPEN-ILS (673-6457) | email: mi...@esilibrary.com | web: http://www.esilibrary.com
