RemoveDataFromCache needs at least an ObjectPersisterFactory to remove all data

[stephanenicolas]

When there is no factory or no persister, nothing is cleared.

[dpsm]

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

[stephanenicolas]

What bugs me with this approach is that you can't start a new instance of
your application and hope to remove all data that was cached by previous
instance(s).

But I don't have any better idea 'till now...

Anyone ?

2013/5/20 David Sobreira Marques notifications@github.com

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

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/98#issuecomment-18127010
.

Stéphane NICOLAS,
OCTO Technology
Développeur & Consultant Android / Java
..........................................................
50, Avenue des Champs-Elysées
75008 Paris
+33 (0)6.26.32.34.09
www.octo.com - blog.octo.com
www.usievents.com
...........................................................

[dpsm]

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.

1. change the caching folder to use a sub folder for the cache manager inside the app cache folder. Then it would be easy to just delete the folder.
2. Add a known prefix to all files created by the cache manager and then remove all files in the current cache folder matching the prefix.

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?

[stephanenicolas]

Hi David,

I like the first solution better than the second. It seems to me we shall
have had this dedicated cache folder since the beginning. It should also be
customizable.

If the problem could be solved that way for file persisters, and doesn't
really mean anything for in memory persisters, what about database
persisters ?

Thx for your contribution,
Stéphane

2013/5/20 David Sobreira Marques notifications@github.com

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.

change the caching folder to use a sub folder for the cache manager
inside the app cache folder. Then it would be easy to just delete the
folder.
2.

Add a known prefix to all files created by the cache manager and then
remove all files in the current cache folder matching the prefix.

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?

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/98#issuecomment-18145304
.

Stéphane NICOLAS,
OCTO Technology
Développeur & Consultant Android / Java
..........................................................
50, Avenue des Champs-Elysées
75008 Paris
+33 (0)6.26.32.34.09
www.octo.com - blog.octo.com
www.usievents.com
...........................................................

[dpsm]

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.

[stephanenicolas]

I came up with the idea this morning that the spice service knows the table
it uses to cache data, from the beginning of the app.

We could just drop them and recreate them. Or, may be better, read the
cache entry table and remove the cached records as others may have been
added outside of RoboSpice caching system. But, maybe devs would want to
wipe out the tables anyway....

What do you think ?

Stéphane

2013/5/21 David Sobreira Marques notifications@github.com

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.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/98#issuecomment-18210430
.

Stéphane NICOLAS,
OCTO Technology
Développeur & Consultant Android / Java
..........................................................
50, Avenue des Champs-Elysées
75008 Paris
+33 (0)6.26.32.34.09
www.octo.com - blog.octo.com
www.usievents.com
...........................................................

[dpsm]

@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/
/ database1.db
/ database1.db.robospicedb
/ database2.db

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?

[stephanenicolas]

Hi David,

sorry for the delay, I suggest that we don't worry about the migration and
let developers perform the migration, a cache clean up in most cases.
Simply asking users to wipe their cache / data should be enough.

You approach for the data base is interesting, wiping out individual
records is also nice, and removing the databases doesn't look to me as an
ugly solution.

I can't see clearly the respective benefits / drawbacks (including in
complexity) of each approach.

Stéphane

2013/5/22 David Sobreira Marques notifications@github.com

@stephanenicolas https://github.com/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/
/ database1.db
/ database1.db.robospicedb
/ database2.db

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?

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/98#issuecomment-18278294
.

Stéphane NICOLAS,
OCTO Technology
Développeur & Consultant Android / Java
..........................................................
50, Avenue des Champs-Elysées
75008 Paris
+33 (0)6.26.32.34.09
www.octo.com - blog.octo.com
www.usievents.com
...........................................................

[stephanenicolas]

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.