-
Notifications
You must be signed in to change notification settings - Fork 545
RemoveDataFromCache needs at least an ObjectPersisterFactory to remove all data #98
Comments
A few ideas on this topic: Same approach as CacheManager.getObjectPersister(..) which throws a RuntimeException if no persisters are found; Another option would be to verify if there is at least one persister added to the cache manager after calling the overriden method SpiceService.createCacheManager(..) during initialization? I like the latter better... Thoughts? David |
What bugs me with this approach is that you can't start a new instance of But I don't have any better idea 'till now... Anyone ? 2013/5/20 David Sobreira Marques notifications@github.com
Stéphane NICOLAS, |
If all we need is to remove all cached data do we even need persisters at all? I would think that we should remove all cached data without invoking any persister. In order to accomplish that we'd need to either.
Not sure how to solve the backwards compatibility issue to clear the existing data after upgrade. Seems that if we call the registered persisters they will clean old data and then we can use one of the new strategies? |
Hi David, I like the first solution better than the second. It seems to me we shall If the problem could be solved that way for file persisters, and doesn't Thx for your contribution, 2013/5/20 David Sobreira Marques notifications@github.com
Stéphane NICOLAS, |
Sqlite databases are a little trickier since they by default all live in the apps databases folder. I would think that for the database based persisters we either should use a name prefix to allow resolving the databases to clear or somehow track them in a persistent registry? Thoughts? Once we come up with a solution I'll be happy to contribute. |
I came up with the idea this morning that the spice service knows the table We could just drop them and recreate them. Or, may be better, read the What do you think ? Stéphane 2013/5/21 David Sobreira Marques notifications@github.com
Stéphane NICOLAS, |
@stephanenicolas I am not quite sure we are on the same page on this topic so let's exchange some more thoughts here :) My understanding is that this bug is about the CacheManager.removeAllDataFromCache(); API does not clear the cache if there are no persisters registered? What use cases would get to this state where there are no persisters anymore and stale cached content? In case we want to move on with the cache specific folder for the file persisters, I am wondering if we would like to support the migration of the already cached content into this new folder when the application upgrades to use the library after these changes? Cached content in the /cache/ folder would need to be migrated into /cache/robospice/. Now the question is how? The current code base does not allow us to determine which files are created by robospice and which ones are not? Maybe we can just decide not to perform migration? Regarding the sqlite based persisters I had an idea. We could take advantage of the method: RoboSpiceDatabaseHelper.onCreate(..) and create a marker file matching the respective database name on the databases folder. The marker is just an empty file to allow tracking the robospice cached dbs. This would create something like this in the file system: /databases/ The cache manager would then look into this folder for *.robospicedb files and remove these along with their marked databases. This would keep the other databases intact and allow cleaning the robospice cache dbs. Thoughts? |
Hi David, sorry for the delay, I suggest that we don't worry about the migration and You approach for the data base is interesting, wiping out individual I can't see clearly the respective benefits / drawbacks (including in Stéphane 2013/5/22 David Sobreira Marques notifications@github.com
Stéphane NICOLAS, |
Cache clean up is working fine for InFileObjectPersisters. For memory, as there is no factory, problem didn't apply. For data bases, a solution needs to be found still. |
When there is no factory or no persister, nothing is cleared.
The text was updated successfully, but these errors were encountered: