Bug 31194 - koha-marc mappings not invalidated in cache
Summary: koha-marc mappings not invalidated in cache
Status: In Discussion
Alias: None
Product: Koha
Classification: Unclassified
Component: Architecture, internals, and plumbing (show other bugs)
Version: unspecified
Hardware: All All
: P5 - low normal (vote)
Assignee: Jonathan Druart
QA Contact: Testopia
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2022-07-20 07:35 UTC by Jonathan Druart
Modified: 2022-07-20 17:06 UTC (History)
4 users (show)

See Also:
Change sponsored?: ---
Patch complexity: ---
Documentation contact:
Documentation submission:
Text to go in the release notes:
Version(s) released in:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
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.