Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Refactor state group lookup to reduce DB hits #4011
Currently when fetching state groups from the data store we make two
I think I'm going to stop now. Suffice it to say that this stuff is fiddly.
I do wonder if we're massively over-complicating this by trying to find a general solution. It might be informative to audit how
filtered_types are actually used, and consider if we ought to be caching at a different level, or something.
Absolutely we are over-complicating this,
I've changed a bunch of the code to bundle a lot of the logic in handling
One problem here is that currently the unit tests do not test these code paths very well, since we prefill our state caches on insertion. Commenting out the prefill will test the code correctly. The question is, how do we want to ensure the code is tested while keeping the behaviour the same in production? We can explicitly clear the caches after insertion in our storage state caches, or have a parameter that turns off prefilling?
oh gosh. I'd hoped that if we refactored all this to use a separate Filter object, we could avoid the whole headfuck of the
There are multiple ways to do this (one option would be an interface which could be implemented by various implementations like a
AllMembersStateFilter or a
I think a more practical impl would be to make the attributes
non_member_types and provide some helper functions to construct the objects.
And yeah, I know that means rewriting a lot more stuff :/
Right, first off, I'm so sorry I regret ever setting eyes on
On the other hand,
In the end I didn't change
Ideally we could then easily change the cache to store the
Everything would then be fine and lovely and we should never touch the state store ever again.
this is generally looking much saner. Sorry about the number of comments but I think they're all fairly easy to resolve.