the localstroage key todosCache/set/{"gruppe":"besteck"} has the value [2,3,4]
if in the second request the instance 4 will not be responsed with, the value of the todosCache/set/{"gruppe":"besteck"} changes to [2,3]. thats fine! but the key todosCache/instance/4 still exists in storage.
can-connect should check any instance if it is on a set, if not, delete the instance in storage.
There's a problem here ... what if something like the following happens:
.getList({group: "house"}) --> 2,3,4
// then
.get({id: 4})
// then
.getList({group: "house"}) --> 2,3
Then 4 shouldn't be removed from the instances data.
I think there are 2 solutions:
Store that updateData was was used on 4. That way 4 doesn't get removed by the 2nd getList. However, this is fraught with problems.
Implement a least recently used (LRU) cache. This would keep 4 in localStorage, but mark it as not being read very much, eventually removing it.
Ideally, the LRU cache could sit on-top of any other connection.
updateListData: function(listData, set){
// check if there's room
if( this.availableSize() < = CURRENT_SIZE + SIZE_OF(listData) )
// get the saved data in the underlying connection.
base.getSets()
base.getInstances() // might need to be added. This is sorta like a .getList({}).
// go through and remove smallest ... repeat until we can fit listData
}
// for every instance
},
getListData: function(set){
base.getListData().then(function(listData){
INCREMENT_AND_TIMESTAMP( set );
response.data.forEach(function(instance){
INCREMENT_AND_TIMESTAMP( instance );
})
})
}
@pYr0x commented on Sun Nov 22 2015
can-connect does not delete the instance in localstorage if they are not present in any sets anymore.
if we received a response like that:
the localstroage key
todosCache/set/{"gruppe":"besteck"}
has the value[2,3,4]
if in the second request the instance 4 will not be responsed with, the value of the
todosCache/set/{"gruppe":"besteck"}
changes to[2,3]
. thats fine! but the keytodosCache/instance/4
still exists in storage.can-connect should check any instance if it is on a set, if not, delete the instance in storage.
@justinbmeyer commented on Thu Sep 01 2016
I think the fix to this will be to go through all the ids of the sets stored and see what ids are not present and delete them.
@justinbmeyer commented on Mon Oct 03 2016
There's a problem here ... what if something like the following happens:
Then 4 shouldn't be removed from the
instances
data.I think there are 2 solutions:
updateData
was was used on4
. That way4
doesn't get removed by the 2ndgetList
. However, this is fraught with problems.4
in localStorage, but mark it as not being read very much, eventually removing it.Ideally, the LRU cache could sit on-top of any other connection.
@pYr0x commented on Mon Oct 03 2016
that is to confusing for me ;) but i think you will do a great job :)