This PR is a Proof of concept, so should not be merged. I want to get these ideas vetted before moving forward.
Changes in this PR
- Extracted the
$idArchives cache in Archive.php to a separate class that is loaded through DI. This decouples the cache from the specific Archive instance that holds it. It also makes the cache last throughout a request.
- Extract archive ID fetching, archive data fetching & archiving process initialization from Archive.php to a new class called ArchiveTableStore. I didn't want to spend too much time changing things if this wasn't deemed a good idea, so I just moved code, I didn't refactor existing code.
- Extract Archive instance creation into a new ArchiveQueryFactory class. This required making the Archive class constructor public.
Changes that haven't been made yet
- Adding the archive table insertion code in ArchiveProcessor (& whatever other classes) to ArchiveTableStore.
- Extracting the archive initialization process from ArchiveTableStore somehow (haven't thought of how).
- Creating an interface for ArchiveTableStore to implement (called RecordDataStore or something) to generalize & specify how "archive data" is stored.
These don't have to be done in a single PR.
The purpose of these changes are to allow plugins to do the following things:
- Override Archive instance creation via the new factory class to handle, eg, new period types.
- Supply a custom ArchiveTableStore to Archive class so it's possible to bypass archiving entirely for certain requests.
Together this will allow re-using other plugins' API methods that serve reports w/ a custom period type and/or disabling the use of the archive tables (so the request always aggregates & doesn't store new data in the archive tables).
Other things it might enable
Eventually the use of a RecordDataStore interface might enable different backends being used for archive data.