[Koha-bugs] [Bug 11232] Retrieve facets from Zebra

[bugzilla-daemon at bugs.koha-community.org]

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11232

--- Comment #32 from David Cook <dcook at prosentient.com.au> ---
(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.