Issue 3589 - Split file reference store interface into queries and updates

[patchwork01]

Make sure you have checked all steps below.

Issue

• My PR addresses the following issues and references them in the PR title. For example, "Issue 1234 - My Sleeper
  PR"
  • Resolves Split file reference store interface into queries and updates #3589

Tests

• My PR adds the following tests OR does not need testing for this extremely good reason:
  • Covered by existing tests

Documentation

• In case of new functionality, my PR adds documentation that describes how to use it, or I have linked to a
  separate issue for that below.

[rtjd6554]

Trivial point as copied, doesn't read as good English for method name due to plural in files.

Suggestion: arePartitionFilesAssignedToJob

Change not necessary, just raised for discussion as understand why starts with is as well

[patchwork01]

Other options would be partitionFilesAreAssignedToJob, or isEachPartitionFileAssignedToJob, or replace the parameters with an object which describes the condition and make the method name shorter. All the options seem better than how it is now, now that you mention it!

[rtjd6554]

Changes acceptable, small suggestion but purely aesthetic

[gaffer01]

I'm not sure this change adds any value. Any implementation of file reference store needs to support both updates and queries. The hard part is making sure that updates and queries can happen at the same time whilst giving consistent results. Even if we had a state store where queries ran against a different store, that was effectively a cache of the main store, which was updated from the other store that was used for updates, the hard part is still making that correct, and splitting the functionality up so that it is in separate classes implementing separate interfaces seems to me to not be helpful.

[patchwork01]

I'm not sure this change adds any value. Any implementation of file reference store needs to support both updates and queries. The hard part is making sure that updates and queries can happen at the same time whilst giving consistent results. Even if we had a state store where queries ran against a different store, that was effectively a cache of the main store, which was updated from the other store that was used for updates, the hard part is still making that correct, and splitting the functionality up so that it is in separate classes implementing separate interfaces seems to me to not be helpful.

This isn't about splitting up the implementation, although I do personally think that would be more flexible. The implementations still extend StateStore and FileReferenceStore, rather than the new interfaces.

This is just for readability. A number of times I've wanted to look at the queries that are implemented against files in the system, and it's been quite difficult to find all of them with any confidence.