Deleting entry on MAL does not reflect within the app about atarashii HOT 6 CLOSED

Definite fix for 1.2, although it wouldn't be bad to make a 1.1.1 with that.

Quick logic idea:

When fetching the anime/manga list, we count how many items are returned and compare with our table row count for that type. If our number is larger, truncate the table and re-save. We do this per-type so we don't waste too much time cleaning the other type table if it's not needed. The basic idea behind all this is that the website should be the authority for data.

from atarashii.

That would work, though doing that I'm not entirely sure how we would know which entries to remove.

Actually, we can use that to determine if we need to iterate through the data to find out which entries were deleted, but that could bring its own problems (adding and deleting in the same sync would yield same count and then the delete check wouldn't trigger).

The easy way out is check every time, but that's not very efficient is it, this could be trickier than I initially thought.

from atarashii.

Just remove all entries if and only if the item count is different. AFAIK, SQLite supports "truncate", but it does support deletion without a "where" clause, so the way to truncate is:

DELETE FROM [tablename];
VACUUM;

Note that we probably don't need to vacuum, which clears the space used by the table. It's not likely to recover more than a few kilobytes if anything, outweighing the CPU time involved.

If we need to reset autoincrement or anything fancy, the table would need to be dropped and re-created.

from atarashii.

Minor correction. Only remove if the count we get from the web service is less than what we have internally.

The only case I can think where we might have an issue is where an item has been deleted and one or more are added. It would require two syncs to clear that out as our initial count would show more on the web side (thus we don't clean the table) and we save the new items, then when we sync again, we get the count difference and clean the table.

from atarashii.

Another option I thought of that is more elegant:

Add an "synced date" to each item in the table. When we sync against the web service, we put in the current time. After doing a sync, we simply find all rows that haven't been synced on this last run and delete those. Obviously, the only items that wouldn't get the updated timestamp would be ones the service didn't return - deleted items.

from atarashii.

That's brilliant, and very easily done too. That's likely what I'll go with. Thanks!

from atarashii.