[Koha-bugs] [Bug 12478] Elasticsearch support for Koha

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

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

--- Comment #148 from Robin Sheat <robin at catalyst.net.nz> ---
(In reply to Jonathan Druart from comment #147)
> I don't understand the problem with the structure, you could have several
> mappings (it's an arrayref of hashrefs).

Oh, yes, you're right. I missed that bit.

> With this structure I could insert exactly the same data in the tables
> (except if I missed something...).

It's just that it's not a natural representation from a database theory point
of view. Why are the various MARC forms lumped together like that? Why should a
schema change be necessary when (god forbid) a new flavour is added? Actually,
that could be important as if we want to add support for different things into
ES, say importing a feed from a journal provider or whatever, you could use a
flavour to mark how the source is mapped into elasticsearch. Additionally, it
promotes redundancy as you are forced to repeat things to have all the required
combinations, which always causes an icky feeling :)

Essentially, having a proper relational many-to-many is the most expressive and
flexible system that is feasible.

I think I'm OK with moving the attributes (sortable, etc) into the join though.
It probably makes the most sense.

> Yes, it's related to the index_name unique key discussion we had last week.
> We should either move sort, facet, suggest to the join table or remove it,
> but not keep the current structure.
> 
> I am not sure about the gain of having the three tables, we could still know
> what fields are mapped with this MARC field or the inverse (same marc_field
> values).
> Anyway, the current structure force us to duplicate the MARC details,
> because of the sort, facet, suggest, which could differ.

Right, but removing the M-to-M still means we have to duplicate things. And
that'll be why the index was there but problematic, because the attributes are
in the wrong place. The index will (I think) be fine if they get removed. 

> Indeed we could add it later, but don't you think it's worth to let the
> librarians (and devs) search something like "biblionumber:42", which is a
> more familiar term than "ID"?

Oh, good point. Yes, that should be done.

-- 
You are receiving this mail because:
You are watching all bug changes.