Bug 31194 - Koha-to-MARC mappings not always invalidated in cache
Summary: Koha-to-MARC mappings not always invalidated in cache
Status: ASSIGNED
Alias: None
Product: Koha
Classification: Unclassified
Component: Architecture, internals, and plumbing (show other bugs)
Version: unspecified
Hardware: All All
: P5 - low normal
Assignee: Jonathan Druart
QA Contact: Testopia
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2022-07-20 07:35 UTC by Jonathan Druart
Modified: 2023-06-17 12:50 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:
Circulation function:

Attachments
Add an attachment (proposed patch, testcase, etc.)

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.
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.