osf.io icon indicating copy to clipboard operation
osf.io copied to clipboard

Fix number of subject children if not allowed by preprint provider [OSF-7615][EOSF-536]

Open sheriefvt opened this issue 8 years ago • 2 comments

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

sheriefvt avatar Mar 10 '17 20:03 sheriefvt

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 avatar Apr 21 '17 14:04 brianjgeiger

@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.

mfraezz avatar May 04 '17 19:05 mfraezz