[OPEN-ILS-DEV] SRU stuff, 2.1+

[Mike Rylander]

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:  miker at esilibrary.com
 | web:  http://www.esilibrary.com