Inmemory reclaim #23 #24
Conversation
lib/engine.js
Outdated
| @@ -57,7 +57,30 @@ function pickStorage() { | |||
| return inMemoryStore; | |||
| } | |||
|
|
|||
| function isReadSupportedNatively() { | |||
There was a problem hiding this comment.
In theory this is not needed if the prior isSupportedNatively is true but wasnt keen on leaking information between the two tests
There was a problem hiding this comment.
Fixed in the last commit where we now have these isSupportedNatively functions storing the result in a var to be used
|
@bryanmikaelian Are you able to check this out if you get a chance? Thanks :) Also unsure why I cant ping Pooya Jaferian who I have been told is a contact for us in the past |
|
@Dahaden Thanks for sending the PR. I think probably can only ping people who contributed to the repo ... I will take a look at the PR in the next few days |
1 similar comment
|
Happy new year @pooyaj and @bryanmikaelian |
|
Happy new year @Dahaden! Sorry for the delay on this, we are working against few release deadlines, but will try to squeeze this in hopefully during the second half of Jan. |
|
No worries :) thanks for the update! |
|
Hey @pooyaj and @bryanmikaelian ! |
…ed different test for reclaim engine access
…function which gets immediately called and set in a var for reuse
Dahaden
force-pushed
the
inmemory-reclaim-#23
branch
from
5f0328f to
1b6f52a
Compare
This allows us to keep a reference to localstorage for reclaim purposes even when localstorage is full.
Carrying on from #20
When creating an instance of localstorage-retry, Store will grab the defaultEngine and use this for the originalEngine which is used to drive the reclaim mechanism
My assumption inside of the last PR was that defaultEngine would always be localstorage. However, engine runs a check and assigns the store to localstorage or inmemory before the module is resolved.
This means, if localstorage is so full that we cant insert a uuid and "test_value", then we will only ever run reclaim against the inmemory engine.