New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
simplify archiving logic by implementing archiving layer as caching backend #7126
Comments
Everything that makes this part easier and understandable is greatly appreciated 👍 One more use case: If a cache entry is marked as to be invalidated it will be still valid until there is a new archive which shouldn't be a big problem to implement. Challenge as you said performance but that sounds doable. |
👍 |
seems most agree with this nice idea, maybe we can close RFC and create follow up issue for new cache backend etc? |
I think it's a non-trivial, I doubt it can be done by 2.11. |
Moved to 2.12.0, where we can close this RFC and create follow up issue eg. in |
Can't you just move this ticket to Short term and remove 'RFC'? |
done |
The logic that uses and manages archive tables should be simple. If an archive exists, use it. If it doesn't exist, get the report/metric data and cache it in an archive. This is what the logic should be like, but the reality is that the archiving code is a complex mess of object spaghetti.
Since the archive tables function essentially as a cache for report & metric data, we could simplify the code greatly by making the archive tables a Piwik Cache backend.
The resulting Archive.php code might look like:
Possible problems:
The text was updated successfully, but these errors were encountered: