0

So right now in test mode, when I want to add a new field value into my class, I just add it into firebase as well. And Codable will do the work and parse the data from firebase fine. But let's say my app has been released and I have 5k users, that is 5k user's I have to manually add the data or they will all have errors in fetching data because their User class has a new value while the data in firebase doesn't or vice versa.

Is there a workaround for this? I am thinking that it can be fixed by posting to firebase on the client side again so the field values end up matching. But I have another collection that doesn't allow user writes and only reads. My only thought is to create a cloud function and add the new field to all collections.

If I parse it normally using dictionary mapping, I can have new values be optional. Should I just use dict mapping instead of codable? Dict mapping, however is very ugly and long.

Doug Stevenson
  • 297,357
  • 32
  • 422
  • 441
dzren12
  • 41
  • 1
  • 6
  • It sounds like you consider the new field optional. In that case, can't you simply mark it as optional in the codable class? https://stackoverflow.com/questions/44575293/with-jsondecoder-in-swift-4-can-missing-keys-use-a-default-value-instead-of-hav – Frank van Puffelen Oct 03 '20 at 14:43
  • 1
    Ah ok. So get the necessary properties in and from there on out, use optional for updates on the class? – dzren12 Oct 03 '20 at 17:51
  • That's what I'd try. If you're not willing to backfill the existing data, that pretty much by definition means that the new field is optional. – Frank van Puffelen Oct 03 '20 at 19:09
  • (1) Do you update the server every time there is a value change or do you bank all of the changes in that view and update them all if there are changes? (2) I assume you have a snapshot listener on this document and if you do then the changes will be instant on the client (as if it were local) because of Firestore's latency compensation. (3) If you absolutely cannot have a situation where client and server are out of sync, consider using atomic operations (transaction or batch write) which require connectivity. – trndjc Oct 04 '20 at 14:56
  • How I see it: A snapshot listener is attached to a document (call it user settings). When the user toggles a control, for example, to change a value in these settings, it's recorded in the view controller and when the user leaves the view, the server is updated if changes were made to any of the values. Because of latency compensation, the snapshot listener fires "simultaneously" with your call to update the server, which then updates the user settings model (perhaps this is a singleton). When the user returns to that view controller, the changes are reflected, even if the server hasn't... – trndjc Oct 04 '20 at 15:01
  • ...been updated yet because, again, of latency compensation and Firestore's offline capability. The write should eventually succeed so it doesn't matter if there the server doesn't reflect the client because to the user it does. However, if the write eventually fails, when the user returns to the view controller he will just see that control in its old position and have to change it again. This is a nominal price to pay, IMO, for the ability to perform server operations offline. – trndjc Oct 04 '20 at 15:04
  • I think an answer would depend on how you're implementing Firebase and your Codable objects. For example: are you using Firebase code like this [Custom Objects](https://firebase.google.com/docs/firestore/query-data/get-data#custom_objects)? If so, adding additional fields to objects in Firebase will have no impact to those users on an older version of the app as the fields will be ignored. Likewise, if you make fields optional in your codable object and the field doesn't exist in Firestore, then it will just be nil ( or set it to some default value if needed ) – Jay Oct 05 '20 at 20:55

0 Answers0