Bug 39397 - Searching a biblio by timestamp returns a different timestamp
Summary: Searching a biblio by timestamp returns a different timestamp
Status: Pushed to stable
Alias: None
Product: Koha
Classification: Unclassified
Component: REST API (show other bugs)
Version: Main
Hardware: All All
: P5 - low normal
Assignee: Tomás Cohen Arazi (tcohen)
QA Contact: Martin Renvoize (ashimema)
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2025-03-20 14:37 UTC by Tomás Cohen Arazi (tcohen)
Modified: 2025-05-17 18:32 UTC (History)
6 users (show)

See Also:
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 (1.57 KB, patch)
2025-03-21 13:56 UTC, Tomás Cohen Arazi (tcohen)
Details | Diff | Splinter Review
Bug 39397: 'biblio' attributes take precedence over 'biblioitems' in response (1.18 KB, patch)
2025-03-21 13:56 UTC, Tomás Cohen Arazi (tcohen)
Details | Diff | Splinter Review
Bug 39397: Regression tests (1.62 KB, patch)
2025-04-01 09:01 UTC, Jesse Maseto
Details | Diff | Splinter Review
Bug 39397: 'biblio' attributes take precedence over 'biblioitems' in response (1.23 KB, patch)
2025-04-01 09:01 UTC, Jesse Maseto
Details | Diff | Splinter Review
Bug 39397: Regression tests (1.69 KB, patch)
2025-04-02 14:15 UTC, Martin Renvoize (ashimema)
Details | Diff | Splinter Review
Bug 39397: 'biblio' attributes take precedence over 'biblioitems' in response (1.30 KB, patch)
2025-04-02 14:15 UTC, Martin Renvoize (ashimema)
Details | Diff | Splinter Review

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