That's one of the main problems why I didn't focused on a DB yet. We need to figure out how to delete things from the DB and rotate information very quickly. Otherwise, a simple amethyst session will get to 10 GBs of disk usage quite fast..
Login to reply
Replies (5)
Just throwing something out there, maybe there are multiple valid ways to cache events. I think kind 1's have a lower priority to be cached, as they have a pretty short half life
but kind 0 and other events could have different options like refreshing on a timed schedule, or even request at viewing. Like you keep the same kind0 until you want to view the user's profile, so you'll fetch again for the profile view.
Yeah, that is definitely true. I am currently reorganizing our cache for the 100,000 WoT score events the app needs to download to make each lifecycle kind-based if root and attached to other events if not a root kind, like comments, reactions, etc. so, when the cache removes the root event, all the others get deleted, including the WOT events in memory. Then it's all about getting the same thing in disk
Also, I need to find a way to do string interning in disk. Because copying 64-byte IDs and pubkeys everywhere is not a good idea.
*chuckles in ORLY* i just fixed the ORLY build and it has all the things and builds on android. enforces expiry, honors deletes, even has a nice handy wipe function, import and export. being native ARM code also the signatures and codecs are nice and fast
compared to my 7GB installation :P