Is there a way for read-only version objects in Firebase?

Question

I am working on an application that will be cross-platform: web, android, iOS. I have a couple of objects that are designed to indicate some constants, such as real states. For instance:

{ "states": { "VALID": 0, "INVALID": 1 } } 

Now I released clients who use this object, and they went into the wild, but I understand that this object does not meet my needs and needs to be changed. Right now I created an object with a version similar to this:

 { "states2": { "VALID": { "id": 0, "name": "Valid entry" }, "INVALID": { "id": 1, "name": "Invalid entry" } } 

Currently, the plan is to leave the state object, and just get additional data from states2 in new clients, but it seems really scary to leave such a legacy cool around. So to the question:

1) Is there a way for version objects that Firebase provides?

or

2) I just use Firebase so that it is not used?

or

3) Is there a better way to structure this kind of read-only data in Firebase?

Answer 1

• No, Firebase does not have built-in version control.

• Not at all. This is a common problem with updating the database schema in the client-server context I have ever seen. Serving multiple client versions when updating a database schema is not easy, no matter which database you use.

  There are several common ways to handle this:

  • What you have done is the very way to resolve this issue: create a secondary data structure that has a new structure. If the structure can be recorded, this means that you will have to reconcile the records to update both locations. And since you cannot update the old application, you will have to do some of this with a non-client script. Yes, it hurts.

  • One alternative that you sometimes see is a forced update, which means that you keep the top level current-schema-version in your database, and the client checks to see if it can read / write this version. If not, it just breaks off.

• The best structure for any data depends on the needs of your application. Therefore, it is impossible for us to say which is better. Your initial data structure seemed reasonable to me, but you realized that it limits it too much.

  Given that this is read-only (possibly administrative) data, I would recommend setting up an admin control panel for your application. When you add a new state to this panel, it can write it to both places.