Auto-ID for arrays instead of index

[3zzy]

Lets Firebase generate auto-id's if an array or objects is passed.

[dalenguyen]

Thanks for contributing. Can you plain more with an example of this case and update the test file cover this? Thanks,

[3zzy]

When importing data, if you provide an array of objects, they would be imported with their numeric indexes as the key (eg. 0, 1, 2 ..). That's because the import script uses set() by default. To let Firebase generate the IDs, we should use the add() instead.

From the docs:

When you use set() to create a document, you must specify an ID for the document to create. In the case of arrays, all you have are numeric indexes and that is used as key currently.

But sometimes there isn't a meaningful ID for the document, and it's more convenient to let Cloud Firestore auto-generate an ID for you. You can do this by calling add()

Read: https://cloud.google.com/firestore/docs/manage-data/add-data#add_a_document

Also its not recommended to use numeric indexes.

This PR fixes that, but I'm not sure how to write tests for that.

[dalenguyen]

Hi @3zzy, the data structure already has an id for the document from export function. We don't have to regenerate it. Which JSON structure are you trying to import?

https://github.com/dalenguyen/firestore-backup-restore/blob/master/test/import-to-firestore.json

In the example, the document id is already defined: first-key & second-key.

[3zzy]

@dalenguyen Right, but for when the id needs to be auto generated instead of manually defining it, you could pass an array of objects.

So from the above example JSON. Instead of:

{
    "test": {
        "first-key": {
        ...
        "subCollection": {
            "test/first-key/details": {
            ...
            }
        }
        },
        "second-key": {
        ...
        }
    }
}

We pass:

{
    "test": [
        {
            ...
            "subCollection": {
                "details": {
                    ...
                }
            }
        },
        {
            ...
        }
    ]
}

[dalenguyen]

@3zzy you're right. This is another case. I will add the sample file and test cases for supporting this case.