Cache redesign part 4: Split up the dataservices

[artlowel]

References

This ticket corresponds to issue 8 from #718.

That ticket was too big to tackle at once so we split it up in to smaller, more manageable chunks of work.

Description

We encourage every service that corresponds with a rest endpoint to inherit from it. But most endpoints only support a fraction of the methods dataservice provides. So we either inherit, and a lot of methods don't work, or use delegation, but don't have interfaces to enforce which methods the delegating service has.

This makes it possible for someone to add an @dataservice annotation on a service that isn't one, and we'd only know about it at runtime. We should at least create a separate interface for each atomic bit of functionality in dataservice, and perhaps also split up dataservice in to multiple smaller classes, and use composition rather than inheritance for the implementing services.

Proposed Solution

• We'll split dataservice methods up in to chunks of functionality and create interfaces for them.
• e.g. CreateDataService, ReadDataService, PutDataService, PatchDataService, DeleteDataService, SearchDataService, …
• The dataservice implementations don't inherit from dataservice but implement the interfaces for the methods they need
• So DSODataservice would only implement ReadDataService, while CommunityDataService would implement them all.
• What is currently the @DataService annotation would become @ReadDataService and enforce services using it to implement the ReadDataService interface.

This will take an estimated 24 - 32h

[tdonohue]

Tentatively added to 7.1 alongside #741 (both might be done by the same developer at that time)

[tdonohue]

While we could change the priority back, I'm bumping this to high priority (from medium) simply because I'm seeing a lot of cache related issues in other tickets. While I realize this may not solve them all, it seems like cache cleanup & fixing caching issues is becoming very high priority.