On Tue, Jun 8, 2010 at 7:13 AM, Galen Charlton <[email protected]> wrote: > Hi, > > On Jun 7, 2010, at 11:16 PM, Mike Rylander wrote: >> ISTM the same could be achieved without the cost of an XSLT with >> >> //marc:datafie...@tag='245' or (@tag='880' and >> starts-with(./marc:subfie...@code='6']/text(), >> '245'))]/marc:subfie...@code='a'] >> >> I could certainly be missing something, though. > > Indeed it could, but using the XSLT allows the XPath to be more concise > without having to make the user worry about 880 fields beyond remembering to > set format to 'marc21expand880'. In the particular database that inspired > this patch, where for at least the first pass the indexing is based on a > direct mapping of MARC subfields to index names per the legacy ILS's > definitions, there are about 180 MARC tags involved spread among 12 indexes. > The time required to create such indexes during ingest wasn't noticeably > longer that that required for the MODS-based indexes. >
I wouldn't expect it to be slower, so that's good confirmation, but I would expect the pure (if somewhat more complicated) raw marcxml XPath to be noticeably faster. A test of that would be useful information, but not critical to the decision for core inclusion IMO. That being said, I agree that's a reasonable tradeoff to give users -- (potentially ... until tested) better batch ingest speed (I'm not concerned much with per-record costs of XSLT) vs simplified configuration. I'll commit to trunk soon. Thanks! -- Mike Rylander | VP, Research and Design | Equinox Software, Inc. / The Evergreen Experts | phone: 1-877-OPEN-ILS (673-6457) | email: [email protected] | web: http://www.esilibrary.com
