Is there a way to version objects in Firebase that are meant to be read-only?

Question

I am working on an app that will be cross-platform: web, android, iOS. I have a couple objects that are intended to specify some constants, like valid states. For example:

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

Now I've released clients that use this object and they're out in the wild, but I realize this object doesn't meet my needs and it needs to change. Right now I've created a versioned object like this:

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

Right now the plan is to leave the states object, and just get the extra data from states2 in the newer clients, but this seems really terrible to leave that kind of legacy cruft around. So to the question:

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

or

2) Am I just using Firebase in a way it isn't meant to be used?

or

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

Answer 1

1. No, Firebase has no built-in versioning.

2. Not at all. This is a common problem with any database schema upgrade in a client-server context that I've ever seen. Catering for multiple versions of clients while upgrading your database schema is not simple, no matter which database you use.

There are a few common ways of handling this:

• What you've done is the most common way of solving this: create a secondary data structure that has the new structure. If the structure is writeable, that means you'll have to reconcile writes to update both locations. And since you can't update the old app, you'll have to do part of this with a non-client script. Yup, it's painful.

• One alternative you sometimes see is a forced upgrade, which means that you keep a top-level current-schema-version in your database and the client checks whether is can read/write that version. If not, it simply aborts.

3. The best structure for any data, depends on the needs of your application. So it's impossible for us to say what is best. Your initial data structure seemed reasonable to me, but you found out it was too limiting.

Given that this is read-only (probably administrative) data, I'd recommend setting up an admin dashboard for your application. When you add a new state in that dashboard, it can write it to both places.