Bug 39397

Summary: Searching a biblio by timestamp returns a different timestamp
Product: Koha Reporter: Tomás Cohen Arazi (tcohen) <tomascohen>
Component: REST APIAssignee: Tomás Cohen Arazi (tcohen) <tomascohen>
Status: Pushed to stable --- QA Contact: Martin Renvoize (ashimema) <martin.renvoize>
Severity: normal    
Priority: P5 - low CC: jonathan.druart, m.de.rooy, martin.renvoize, nick, paul.derscheid, tomascohen
Version: Main   
Hardware: All   
OS: All   
See Also: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39558
GIT URL: Change sponsored?: ---
Patch complexity: Small patch Documentation contact:
Documentation submission: Text to go in the release notes:
Version(s) released in:
25.05.00,24.11.04
Circulation function:
Attachments: Bug 39397: Regression tests
Bug 39397: 'biblio' attributes take precedence over 'biblioitems' in response
Bug 39397: Regression tests
Bug 39397: 'biblio' attributes take precedence over 'biblioitems' in response
Bug 39397: Regression tests
Bug 39397: 'biblio' attributes take precedence over 'biblioitems' in response

Description Tomás Cohen Arazi (tcohen) 2025-03-20 14:37:10 UTC
When crafting a search including the `timestamp` field, the comparison is made against the `biblio.timestamp` column. But the result displays the `biblioitem.timestamp`.

I believe filtering and the returned objects should be consistent.

On the other hand, I feel like the real source for truth is the biblio_metadata.timestamp column.

Thoughts?
Comment 1 Tomás Cohen Arazi (tcohen) 2025-03-21 13:56:18 UTC
Created attachment 179609 [details] [review]
Bug 39397: Regression tests

Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Comment 2 Tomás Cohen Arazi (tcohen) 2025-03-21 13:56:21 UTC
Created attachment 179610 [details] [review]
Bug 39397: 'biblio' attributes take precedence over 'biblioitems' in response

This patch swaps biblio for biblioitem attributes in the return value.
The effect is that attributes from the `biblio` table overwrite those
named the same (`timestamp` being the target).

To test:
1. Apply the regression tests patch
2. Run:
   $ ktd --shell
  k$ prove t/db_dependent/api/v1/biblios.t
=> FAIL: The biblioitems.timestamp is returned!
3. Apply this patch
4. Repeat 2
=> SUCCESS: Things go smooth now
5. Sign off :-D

Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Comment 3 Jesse Maseto 2025-04-01 09:01:43 UTC
Created attachment 180097 [details] [review]
Bug 39397: Regression tests

Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Jesse Maseto <jesse@bywatersolutions.com>
Comment 4 Jesse Maseto 2025-04-01 09:01:46 UTC
Created attachment 180098 [details] [review]
Bug 39397: 'biblio' attributes take precedence over 'biblioitems' in response

This patch swaps biblio for biblioitem attributes in the return value.
The effect is that attributes from the `biblio` table overwrite those
named the same (`timestamp` being the target).

To test:
1. Apply the regression tests patch
2. Run:
   $ ktd --shell
  k$ prove t/db_dependent/api/v1/biblios.t
=> FAIL: The biblioitems.timestamp is returned!
3. Apply this patch
4. Repeat 2
=> SUCCESS: Things go smooth now
5. Sign off :-D

Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Jesse Maseto <jesse@bywatersolutions.com>
Comment 5 Martin Renvoize (ashimema) 2025-04-02 14:15:48 UTC
Created attachment 180398 [details] [review]
Bug 39397: Regression tests

Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Jesse Maseto <jesse@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@openfifth.co.uk>
Comment 6 Martin Renvoize (ashimema) 2025-04-02 14:15:50 UTC
Created attachment 180399 [details] [review]
Bug 39397: 'biblio' attributes take precedence over 'biblioitems' in response

This patch swaps biblio for biblioitem attributes in the return value.
The effect is that attributes from the `biblio` table overwrite those
named the same (`timestamp` being the target).

To test:
1. Apply the regression tests patch
2. Run:
   $ ktd --shell
  k$ prove t/db_dependent/api/v1/biblios.t
=> FAIL: The biblioitems.timestamp is returned!
3. Apply this patch
4. Repeat 2
=> SUCCESS: Things go smooth now
5. Sign off :-D

Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Jesse Maseto <jesse@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@openfifth.co.uk>
Comment 7 Katrin Fischer 2025-04-11 06:31:40 UTC
Adding Nick here for another opinion before pushing since he talked to me about this issue in Marseille and I have a strong feeling there is another bug somewhere about this thing... 

Also: how is biblioitems better than biblio in terms of timestamp? Both will only be updated if one of the mapped columns is, I believe?
Comment 8 Marcel de Rooy 2025-04-11 07:39:30 UTC
Think that the timestamp column should be just related to the update of that specific table. And that may be a bit awkward when we move data to tables like biblio_metadata which is (theoretically) no longer 1-1 btw.

The question 'did this biblio change' should be more specific. Do you mean whether the MARC record changed? But there might be another schema too? Did the biblio change when we change an item (affecting the marcxml when embedding items)? Etc.
Comment 9 Nick Clemens (kidclamp) 2025-04-11 12:50:31 UTC
This one is straightforward I think - a query on timestamp on the biblios endpoint should return the biblios value for timestamp - right now we query against biblio and return biblioitems - that makes it look like the results are wrong

Bug 39558 suggests that we should keep the timestamps in sync, and may need more discussion
Comment 10 Katrin Fischer 2025-04-11 12:52:30 UTC
Thanks Nick!
Comment 11 Katrin Fischer 2025-04-14 06:52:59 UTC
Pushed for 25.05!

Well done everyone, thank you!
Comment 12 Paul Derscheid 2025-04-22 20:28:39 UTC
Nice work everyone!

Pushed to 24.11.x for 24.11.04