Mon, 27 Aug 2018 12:40:41 +0200 stablerange: rework saving logic to be clearer and safer stable
Pierre-Yves David <pierre-yves.david@octobus.net> [Mon, 27 Aug 2018 12:40:41 +0200] rev 4026
stablerange: rework saving logic to be clearer and safer
Mon, 27 Aug 2018 12:12:49 +0200 obshashrange: rework saving branching to be clearer and safer stable
Pierre-Yves David <pierre-yves.david@octobus.net> [Mon, 27 Aug 2018 12:12:49 +0200] rev 4025
obshashrange: rework saving branching to be clearer and safer
Mon, 27 Aug 2018 11:40:32 +0200 sqlcache: protect read query too stable
Pierre-Yves David <pierre-yves.david@octobus.net> [Mon, 27 Aug 2018 11:40:32 +0200] rev 4024
sqlcache: protect read query too Some error (like locked database) can even happens when doing readonly operation. So we protect them too. At that point, it seems that pysqlite3 is not the right tool for this job.
Mon, 27 Aug 2018 11:33:09 +0200 sqlite: fast path when nothing to save stable
Pierre-Yves David <pierre-yves.david@octobus.net> [Mon, 27 Aug 2018 11:33:09 +0200] rev 4023
sqlite: fast path when nothing to save If we have no new data to save, we should try to do anything. Doing something concurrently is hard enough. If we can avoid doing it at all that would be great.
Mon, 27 Aug 2018 11:27:04 +0200 sqlcache: initialize meta table last stable
Pierre-Yves David <pierre-yves.david@octobus.net> [Mon, 27 Aug 2018 11:27:04 +0200] rev 4022
sqlcache: initialize meta table last It turns out that pysqlite commit after each table creation. This commit is an hopeless attemps to make the caches more concurrent friendly.
Mon, 27 Aug 2018 10:20:15 +0200 obshashrange: always check in base cachekey against the recorded one stable
Pierre-Yves David <pierre-yves.david@octobus.net> [Mon, 27 Aug 2018 10:20:15 +0200] rev 4021
obshashrange: always check in base cachekey against the recorded one Ignoring the check in the none case is just disaster waiting to happens.
(0) -3000 -1000 -300 -100 -30 -10 -6 +6 +10 +30 +100 +300 +1000 tip