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?
Created attachment 179609 [details] [review] Bug 39397: Regression tests Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
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>
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>
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>
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>
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>
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?
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.
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
Thanks Nick!
Pushed for 25.05! Well done everyone, thank you!
Nice work everyone! Pushed to 24.11.x for 24.11.04