Renames CachedObjectStorage to Collection/Cells #104
Conversation
|
You are right, after I created this pr I discovered the real function of
these classes.
I had an idea about a off memory collection. Will try to create a prove of
concept for that and mention that in #3
Op zo 26 feb. 2017 07:02 schreef Adrien Crivelli <notifications@github.com>:
… That seems a bit early to create a PR when no decision was made in #3
<#3> about what we
should do. If PSR is indeed implemented I suppose it would more efficient
to refactor everything in a single pass. I am tempted to close this, but
I'll leave it open until a decision is made in #3
<#3>.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#104 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ABAuUX7-64QN-dJhm1i8z3H_RvYdLy55ks5rgRVogaJpZM4MMAm1>
.
|
And what exactly did you understand from the code ? I am interested in your opinion because I am not very familiar with this part yet and your views may differ from mine... |
|
I thought is was some kind of caching layer to speed things up, but is isn't. It is literally the collection of cells in a workspace. Which makes sense acually since the number of cell objects can be quite large. The different implementations are just to use different backends |
|
The purpose was purely to reduce memory overhead of large numbers of cell objects, providing a way of holding the cell objects outside of PHP memory, and offering a range of different out-of-memory options that would suit users with different environments, and access to different cache libraries (redis/memcache/APC/etc) that could be used for out-of-memory storage |
|
This won't be merged in favor of a more in depth refactoring |
This applies the first step to refactor the cache of cells.
Refs #3