http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11232
--- Comment #32 from David Cook <[email protected]> --- (In reply to wajasu from comment #31) > Idea: To determine which indexes get the additional index:0, we could: > provide a UI(similiar to msaby's suggestion that allows us to select an > index by grabbing the <target_index> nodes from biblios-koha-indexdefs.xml, > and search replacing > <target_index>index:p</target_index> with > <target_index>index:p</target_index><target_index>index:0</target_index> > (control_field, data_field, sub_field savy UI is possible) > I think that this is a bad idea. 1) I'm not 100% sure, but I think that many installs of Koha run multiple sites using one set of Zebra configs. At least, that's how it appears to work on package installs. I suppose you could have this be an additive process that checks if "index:0" exists and if not, you can add it, when you want to use that index. That wouldn't screw with other people's indexing too much. But I'm not sure allowing the web server to write files in /etc/koha/ is the best idea. 2) Increasingly, I'm becoming less sure that librarians themselves actually need web access to this type of configuration. I think it is a good idea to have configurable facets, but perhaps having a separate file for this would be best. A sysadmin could then edit it as needed. > When querying the chosen facets, it might be worth querying the whole list > at once and if it fails, querying each sequentially such that if one fails, > we just don't supply that label to the UI and log the failing facet, > refering them to the facet config UI to reconcile. But things continue to > run. > I don't follow you 100% here. I originally thought that you meant we could query zebra for our chosen facets, and if that failed, that we could choose do each individually. That would probably make sense so that facets didn't entirely bust for one badly configured facet. > It might be worth looking into generating > retreival-info-bib-grs1-faceted.xml and biblios-koha-indexdefs-faceted.xml > and launching xsltproc to generate biblio-zebra-indexdefs-faceted.xsl, > without touching the original configs. Facets could be disabled to enable > non-faceted searching until the issue is resolved. > > We might also employ xi:include and fallback in koha-conf.xml to use the > faceted file(s) which could be generated/removed by the facet config UI. > <xi:include href="/home/koha/koha-dev/etc/zebradb/retrieval-info-bib-dom.xml" > xmlns:xi="http://www.w3.org/2001/XInclude";> > <xi:fallback> > Thus leaving koha-conf.xml flexible. > > Mapping tags to new indexes that go in biblios-koha-indexdefs.xml can > possibly be a separate effort. > I really think this is getting overly complex. This would likely take quite a bit of code just to add a web UI that most librarians will probably (and should probably) never touch. -- I think the best idea is probably to add "index:0" for our current range of facets, and add it to a few other desired facets (such as pubdate). We put the list of indexes in a file, make sure that those indexes are sent off to Zebra when doing a facet query, and that's that. If a web UI is really necessary, perhaps reading the list of indexes out of that file would make sense. Perhaps the file would be unnecessary and we could just read out the "index:0" facets from the Zebra config, but I would be hesitant about adding them in... ...especially since adding "index:0" and sending a facet query referencing that new index:0 before doing a full re-index will break the facets (if sent as one combined query and not lots of separate ones). -- I'm not saying I have a perfect idea in mind, but I think... we shouldn't try to be too fancy or convoluted. Simple and elegant. We provide a set of default facets, and if folks want to add their own, we leave them with good enough instructions to do so. I really don't want to be dynamically messing with files that should be static. -- You are receiving this mail because: You are watching all bug changes. _______________________________________________ Koha-bugs mailing list [email protected] http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
