5

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?

Community
  • 1
  • 1
prodaea
  • 1,720
  • 1
  • 14
  • 20

2 Answers2

8

  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.

  1. 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.

Frank van Puffelen
  • 565,676
  • 79
  • 828
  • 807
0

Assuming you have an old app v1.0 and a new one v2.0, you have 50 clients reading/writing as per v1.0 and 50 clients reading/writing as per v2.0.

The only question is if those groups of clients interact with each other or not?

If no, they are happy with their app.

If yes, v2.0 clients have to read data from v1.0 fields and upgrade it to v2.0 fields (default or with additional data from v2.0 clients) and while writing write v1.0 fields and then write additional v2.0 fields.

The theory applies to one client interacting with multiple other version clients.

Since firebase is schemaless, you can have two nodes of same category containing different number of fields, without problem. Hence with firebase, you should only take care that you won’t change the meaning of a field between the versions. In the newer versions, always keep the old read/writes as it is and for the new data always create new fields.

Minimum required fields for a version to function must always be present in all higher versions of your product.

Amit Agrawal
  • 1