Fix number of subject children if not allowed by preprint provider [OSF-7615][EOSF-536]
Purpose
Subjects might have children that the provider does not allow. There is an API response for any single subject listing its children. There is a need to fix the API side so that the serializer show the real children count based on the current provider.
Changes
- Update preprint_provider view.
- Count number of children for each subject, if only allowed by the current preprint provider.
- Store the count into a subject attribute 'child_count_provider'.
- Update serializer.
- Use a new method that checks if the subject has the 'child_count_provider' and returns its value. Otherwise, returns all the children.
Side effects
The response time for the API has been recorded. The extra step needed for searching and counting the children added an extra time to the API response (approx. 3-4x times slower at worst case scenario). This effect is noted with large lists (e.g. Arts and Humanities subject under SocArXiv)
Ticket
https://openscience.atlassian.net/browse/OSF-7615 https://openscience.atlassian.net/browse/EOSF-536
Hey, @mfraezz, I expect your custom taxonomy stuff is going to intersect here, yes? Will you have a better way of ensuring that the count is right on your stuff? (And by "better" I mean with a sql query or naturally based on your new data structure instead of, say, with a list comprehension like we've had to do in the past)
@brianjgeiger Yes, on both accounts. This will conflict, and could be done more optimally for any provider that has confirmed their desired taxonomy mapping.
@sheriefvt If you feel so inclined, you could redo this off of the feature/custom-taxonomies branch. You could reuse the existing behavior here for providers without populated subjects, and use the reverse FK subjects for those that do.
Update: this should already be fixed incidentally for mapped providers on that branch. Given that they'll all need a mapping eventually, this issue may not be worth pursuing.