[Koha-bugs] [Bug 20271] Merge deleted biblio, biblioitems, biblio_metadata, and items tables

[bugzilla-daemon at bugs.koha-community.org]

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20271

--- Comment #195 from Tomás Cohen Arazi <tomascohen at gmail.com> ---
(In reply to Jonathan Druart from comment #193)
> Note for myself:
> 
> * comment 182
> 
> * comment 183
> 
> * comment 184
> 
> * deal with reports

This should be done using DB views. What is the 'deleted' column name we
picked?

> * my $item_object = Koha::Items->find({barcode => $barcode });
> => We need to remove the barcode unique index

We need to rely on the DB to handle barcode uniqueness... we should move the
barcode to another column, say... deleted_barcode.

> * Prevent regression and deal with Koha::Items->find Koha::Items->search
> Ideas:
>   - ->find returns only non-deleted items when ->find_deleted returns only
> deleted items
>   - same for ->search, ->search_deleted
> 
> Or keep Koha::Old::Items that could inherit from Koha::Items
> 
> Or update all the occurrences (how many?)

On the API I would expect the endpoint to return non-deleted ones as default,
and I would prefer to handle it explicitly: manually adding deleted => 0 to the
query. And have ?include_deleted=true and/or ?deleted=true be mandatory to get
the deleted ones.

Maybe we could encapsulate this pattern in Koha::Objects::Deleted, which
extended Koha::Objects with new generic methods: ->search_without_deleted

I haven't made up my mind yet, but I feel it smells to have ->search have a
weird behaviour other than the expected.

I'm also worried how we would handle:

my $items = $biblio->items;

so it doesn't return deleted ones.

-- 
You are receiving this mail because:
You are watching all bug changes.