[Koha-bugs] [Bug 20028] Export all patron related personal data in one package

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

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

--- Comment #26 from Lari Taskula <lari.taskula at hypernova.fi> ---
(In reply to Johanna Räisä from comment #25)
> If we return only itemnumbers then the item data have to be fetched from
> items-endpoint. It is not very efficient to have hundreds of API calls to
> get rest of the data. I think it is better to have at least an expanded
> endpoint for more information.
Good point. While one could argue that since item data is not directly part of
patron related data and should not be returned, I can see use cases where it
makes sense to expand.

Expanded objects contain a lot unwanted data, so we would have to select which
columns to expand.

By the way, there are 52 tables that are directly related to a patron via DBIx
relationship (meaning foreign keys in borrowers table, or foreign keys in other
tables pointing to borrowers). These are:

3 belongs_to relationship (borrowers refer to primary key in other table):
branches
categories
sms_providers

(the three tables above have a lot of data that should probably be left out?)

49 has_many relationship (tables that refer to borrowers):
accountlines
advanced_editor_macros
alert
api_keys
aqbasketusers
aqbudgetborrowers
aqorder_users
aqorders
article_requests
borrower_attributes
borrower_debarments
borrower_files
borrower_message_preferences
borrower_relationships
cash_register_actions
club_enrollments
club_holds_to_patron_holds
course_instructors
creator_batches
discharges
hold_fill_targets
housebound_profile
housebound_role
housebound_visit
illcomments
illrequests
issues
items_last_borrower
message_queue
messages
old_issues
old_reserves
opac_news
patron_consent
patron_list_patrons
patron_lists
patronimage
problem_reports
ratings
reserves
return_claims
reviews
subscriptionroutinglist
tags_all
tags_approval
user_permissions
virtualshelfcontents
virtualshelfshares
virtualshelves

(most of the ones above could be fully included?)

> Pagination options are mandatory since the return data be massive.
It's a costly operation to get all of that data in the first place. Especially
if we expand it. If we paginate it (it's a good idea), should we cache the
result for some time? Performance tests will come in handy.

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