How does Firebase choose what to store in its cache with isPersistenceEnabled = true in iOS

How does Firebase choose what to store in its cache with isPersistenceEnabled = true in iOS



I have an app that is using Firebase quite extensively to store data that contains relationships. I want to make sure I am using Firebase as safely as possible in offline mode. The safety concern I have can be demonstrated in the following example:



Assume I have a Zoo model where each individual zoo is stored in Firebase as a subnode of "/zoos".



I have an Animal model where each individual animal is stored in Firebase as a subnode of "/animals".



A Zoo can have Animals which are stored in an ordered list. Specifically, the Zoo model contains an Animal array e.g. [Animal]. This list of Animals is stored in Firebase as a set of position-reference pairs at "/zoos/myZoo/animals" which will contain nodes like:
0: "animals/fidoTheDog",
1: "animals/jillTheCat"



When I add a new Animal to a Zoo, I need to know how many animals are currently in that zoo so I can add the new animal in the right position like:
2: "animals/jakeTheSnake"



If I am offline and happen to read the location "zoos/myZoo/animals" to get the list of animals so I can add in the right position, I want to make sure I have accurate data. I know that if someone else wrote to that position while I am offline and added another animal in position 2, I will get stale data and when I add an animal in position 2, I will overwrite his entry at "zoos/myZoo/animals/2" when I again go online. So that is an issue.



But, if I know I will be the only one writing to that location, can I be relatively sure that Firebase will hold the crucial data at "zoos/myZoo/animals" for me since I am using isPersistenceEnabled = true? In other words, will Firebase just keep that data in cache as long as I have recently written to that location or recently read from that location?



Or do I explicitly need to specify "keepSynced(true)" on that location? This gets to the core general version of the question - How does Firebase choose what to store in its cache with isPersistenceEnabled = true? Especially if I have not specifically set keepSynced(true) on any particular locations. Will Firebase just prioritize recently read data and then when the 10mb limit is hit, discard the old stuff first? Does it matter if I wrote the data to that location a long time ago but consistently read from that location? Will it still maintain that location in the cache because it was recently read? Will it ever discard data before hitting the 10mb limit?



I'm a little bit of a newbie so thank you for your patience with me!



-------------- FOLLOW UP QUESTIONS --------------



A couple follow up questions.



I think the approach suggested in the blog (given by Frank in comments) of using childByAutoID sounds good. So if I am saving a zoo with many animals (in order) then it sounds like I would loop through the animals and use childByAutoID to create a new key for each animal whose value will be the reference to the location of the animal object. Can I be sure that the keys that I create in rapid succession (looping will probably be very fast) will ultimately sort correctly when ordered lexicographically? I’m looking at this blog post and assuming that is the case. https://firebase.googleblog.com/2015/02/the-2120-ways-to-ensure-unique_68.html



Suppose I am doing something more complicated like inserting an animal at the beginning of the list in position zero. Then before doing the operation, I would sync down the list of animals in the zoo as suggested in the blog post you sent. https://firebase.googleblog.com/2014/04/best-practices-arrays-in-firebase.html. If the user is offline, I obviously can’t be sure that I will have the freshest copy. But suppose I am ok with that because users will only be working with their own data and only on their own device. In that case, does it help to use keepSynced(true) on the path to the zoo? Or since the amount of data the user is working with is well, well under 10mb (the whole database right now is 300k for 10ish active users), can I just assume the cache will store the data in the zoo path (whether keepSynced or not) because we never flirt with the 10mb limit in any case?



Thank you!





According to the documentation: "By enabling persistence, any data that the Firebase Realtime Database client would sync while online persists to disk and is available offline". That seems to be pretty explicit, but there's not really much else there on the subject. If you need more information maybe you can also reach out to Firebase Support.
– shim
Sep 4 at 3:11






Thanks. But I guess what I want to know is how it treats data that it wouldn't sync while online. If I don't have any listeners set for a location, how long does it still store that data? I know by testing that it is storing the data and I can still access it while offline even though I am not explicitly listening to that location and have not set keepSynced(true) for that location.
– Sumit Kapur
Sep 4 at 3:29





There is no time-based expiration of data in the disk cache. Data is kept in the cache indefinitely, or until the client needs to make space for more recent data. If that is needed, the data that was least recently accessed is removed from the disk cache first.
– Frank van Puffelen
Sep 4 at 3:55






The whole approach with position=2 will keep leading to problems as your solution needs to work when clients are offline, or many clients are writing data in the same branch. Use Firebase's push()/childByAutoId()` to prevent these problems. See firebase.googleblog.com/2014/04/… and firebase.googleblog.com/2015/02/…
– Frank van Puffelen
Sep 4 at 3:58


position=2


push


/





@FrankvanPuffelen Hi Frank. I was actually hoping you would answer the question! Great to meet you. I’m definitely a Firebase fan. I have added a couple follow up questions now in the main post (they wouldn't fit in comments). Thanks.
– Sumit Kapur
Sep 4 at 22:06






Thanks for contributing an answer to Stack Overflow!



But avoid



To learn more, see our tips on writing great answers.



Some of your past answers have not been well-received, and you're in danger of being blocked from answering.



Please pay close attention to the following guidance:



But avoid



To learn more, see our tips on writing great answers.



Required, but never shown



Required, but never shown




By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Popular posts from this blog

𛂒𛀶,𛀽𛀑𛂀𛃧𛂓𛀙𛃆𛃑𛃷𛂟𛁡𛀢𛀟𛁤𛂽𛁕𛁪𛂟𛂯,𛁞𛂧𛀴𛁄𛁠𛁼𛂿𛀤 𛂘,𛁺𛂾𛃭𛃭𛃵𛀺,𛂣𛃍𛂖𛃶 𛀸𛃀𛂖𛁶𛁏𛁚 𛂢𛂞 𛁰𛂆𛀔,𛁸𛀽𛁓𛃋𛂇𛃧𛀧𛃣𛂐𛃇,𛂂𛃻𛃲𛁬𛃞𛀧𛃃𛀅 𛂭𛁠𛁡𛃇𛀷𛃓𛁥,𛁙𛁘𛁞𛃸𛁸𛃣𛁜,𛂛,𛃿,𛁯𛂘𛂌𛃛𛁱𛃌𛂈𛂇 𛁊𛃲,𛀕𛃴𛀜 𛀶𛂆𛀶𛃟𛂉𛀣,𛂐𛁞𛁾 𛁷𛂑𛁳𛂯𛀬𛃅,𛃶𛁼

Edmonton

Crossroads (UK TV series)