fix nplusone whitelist

[gedankenstuecke]

Currently, the admin backend in development gives the above error when trying to look at the UserProfile admin pages. This is because it loops over all UserProfiles which in turn lazy-loads the user.username from the database, c.f. users.models:

def __str__(self):
        return "Profile for {}".format(self.user.username)

These added requests are mainly due to how the admin backend works in presenting & loading this data and I don't think we use the str method anywhere else (otherwise we'd already have stumbled over those errors).

Given this, I just added it to the whitelist, for the nplusone library to not check for this any more (as it's only for performance monitoring)

[github-actions]

Coverage report

The coverage rate went from 98.89% to 98.89% ⬇️

None of the new lines are part of the tested code. Therefore, there is no coverage data about them.

[llewelld]

Thanks for making this change. It was useful for me to read up about this N + 1 query issue. I'm certainly happy with this fix, but was thinking maybe it also makes sense to switch the string identier to something like that below, just to avoid this being a gotcha in potential future debug code?

    def __str__(self):
        return "Profile id {}".format(self.user_id)

[gedankenstuecke]

Thanks @llewelld, that's a good suggestion generally and I thought of making that change but I feel for the admin backend it's actually quite nice to actually be able to browse the profiles by the actual username rather than the user_id?

The problem is that if we'd be using the user_id, the admin interface list will read Profile for 3 instead of Profile for 62620642_openhumans. And as never really use the user_id anywhere the oh_id feels like it'd be more salient to admin users?

[llewelld]

That's fair enough of course. I guess you'll just have to bear in mind that as you gain more users you'll get a lot more queries when using the admin page, but I'm sure you understand the potential consequences of that better than I do already.

[gedankenstuecke]

Yeah, I guess given that we're only using it in the admin backend and not anywhere else it should hopefully be okay and worst-case the admin page of the UserProfile specifically would be a bit slower. But those pages also paginate after around 50 or so entries, so hopefully that limit should also avoid it being a huge issue 🤞 😂