Bug 31194

Summary: Koha-to-MARC mappings not always invalidated in cache
Product: Koha Reporter: Jonathan Druart <jonathan.druart>
Component: Architecture, internals, and plumbingAssignee: Jonathan Druart <jonathan.druart>
Status: ASSIGNED --- QA Contact: Testopia <testopia>
Severity: normal    
Priority: P5 - low CC: joonas.kylmala, martin.renvoize, nick, tomascohen
Version: unspecified   
Hardware: All   
OS: All   
See Also: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=30909
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31195
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31196
Change sponsored?: --- Patch complexity: ---
Documentation contact: Documentation submission:
Text to go in the release notes:
Version(s) released in:

Description Jonathan Druart 2022-07-20 07:35:50 UTC
The cache is cleared for the default framework, but the mapping can be read from another framework
Comment 1 Jonathan Druart 2022-07-20 07:36:07 UTC
Coming from bug 30909 comment 14.
Comment 2 Jonathan Druart 2022-07-20 07:56:23 UTC
Hum, I am not sure what is the best here.

The original problem is that the koha-MARC mapping is not updated when adding/editing items.

So this may be a regression coming from bug 27526, where we are now using the marc subfield structure (mss) from the biblio to retrieve the mapping (kohafield). And before we were calling C4::Biblio::GetMarcFromKohaField.

Either 1. we consider that the kohafield can be retrieved from any mss in cache, or 2. we force the fetch to be done using GetMarcFromKohaField.

2. is easier to implement, 1. is preventing us from hitting the same problem in the future (and certainly better for perfs but nothing bad as GetMarcFromKohaField is cached).

What's your call?
Comment 3 Jonathan Druart 2022-07-20 08:00:16 UTC
For 1. we need a separate cache for biblio frameworks that we could fully cleared when they are modified.
Comment 4 Joonas Kylmälä 2022-07-20 17:06:57 UTC
(In reply to Jonathan Druart from comment #0)
> The cache is cleared for the default framework, but the mapping can be read
> from another framework

I'm pretty sure I used the default framework when noticing this bug for the first time. The cache invalidation problem occurred only when I deleted a mapping, I didn't notice it happening when changing the value of a mapping. I'll try to circle back to this bug report later to confirm / and see if I have any ideas on how to fix this issue.
Comment 5 Katrin Fischer 2023-06-17 12:50:21 UTC
(In reply to Joonas Kylmälä from comment #4)
> (In reply to Jonathan Druart from comment #0)
> > The cache is cleared for the default framework, but the mapping can be read
> > from another framework
> 
> I'm pretty sure I used the default framework when noticing this bug for the
> first time. The cache invalidation problem occurred only when I deleted a
> mapping, I didn't notice it happening when changing the value of a mapping.
> I'll try to circle back to this bug report later to confirm / and see if I
> have any ideas on how to fix this issue.

We only use the default framework now for the mappings - or more, it's authoritative. So that would ont be an issue, but Joonas sounds like there might still be some other issues.