Btukfyl

I'm looking for a proper way to structure Firestore database to handle multiple version histories of documents inside a single collection.

For example: I have a collection named offers which have multiple documents which correspond to multiple offers. For each of these documents, I'd like to have history of changes, something like changes on Google Docs.

Since documents support only adding fields directly or nesting another collection, here's a structure I had in mind:

collections: offers

 - documents: offer1, (offer2, offer3, ...)

     - fields populated with latest version of the offer content

     - nested collection named history

         - nested documents for each version (v1, v2, v3), which in turn have fields specifing state of each field in that version. 

This seems a bit overly complicated since I have latest state and than nested collection for history. Can this be somehow in flat structure where latest item in array is the latest state, or something similar.

Also, history state is generated on a button click, so I don't need every possible change saved in a history, just snapshots when user saves it.

I'd like to use Firebase as my DB for this, as I need it some other things, so I'm not looking into different solutions for now.

Thanks!

EDIT: According to the Alex's answer, here's my another take on this.

Firestore-root

   |

   --- offers (collection)

        |

        --- offerID (document)

        |   (with fields populated )

        |        |

        |        --- history (collection) //last edited timestamp

        |            |

        |            --- historyId

        |            --- historyId

        |

         --- offerID (document)

            (with fields populated with latest changes)

                 |

                 --- history (collection) //last edited timestamp

                     |

                     --- historyId

                     --- historyId

This way I can query whole offers collection and get array of offers together with latest status since it's on the same level as the collection itself. Then if I need specific content from history state, I can query history collection of specific offer and get it's history states. Does this make sense?

I'm not sure about denormalization as this seems like it solves my problem and avoids complication.

Once more, requirements are:
- being able to fetch all offers with latest state (works)
- being able to load specific history state (works)

Just every time I update history collection with new state, I overwrite the fields directly in offerID collection with the same, latest, state.

Am I missing something?

In my opinion, your above schema might work but you'll need to do some extra database calls, since Firestore queries are shallow. This means that Firestore queries can only get items from the collection that the query is run against. Firestore doesn't support queries across different collections. So there is no way in which you can get one document and the corresponding history versions that are hosted beneath a collection of that document in a single query.

A possible database structure that I can think of, would be to use a single collection like this:

Firestore-root

   |

   --- offerId (collection)

        |

        --- offerHistoryId (document)

        |        |

        |        --- //Offer details

        |

        --- offerHistoryId (document)

                 |

                 --- //Offer details

If you want to diplay all history versions of an offer, a single query is required. So you just need to attach a listener on offerId collection and get all offer objects (documents) in a single go.

However, if you only want to get the last version of an offer, then you should add under each offer object a timestamp property and query the database according to it descending. At the end just make a limit(1) call and that's it!

Edit:

According to your comment:

I need to get a list of all offers with their latest data

In this case you need to create a new collection named offers which will hold all the latest versions of your offers. Your new collection should look like this:

Firestore-root

   |

   --- offers (collection)

        |

        --- offerHistoryId (document)

        |        |

        |        --- date: //last edited timestamp

        |        |

        |        --- //Offer details

        |

        --- offerHistoryId (document)

                 |

                 --- date: //last edited timestamp

                 |

                 --- //Offer details

This practice is called denormalization and is a common practice when it comes to Firebase. If you are new to NoQSL databases, I recommend you see this video, Denormalization is normal with the Firebase Database for a better understanding. It is for Firebase realtime database but same rules apply to Cloud Firestore.

Also, when you are duplicating data, there is one thing that need to keep in mind. In the same way you are adding data, you need to maintain it. With other words, if you want to update/detele an item, you need to do it in every place that it exists.

In your particular case, when you want to create an offer you need to add it in two places, once in your offerId collection and once in your offers collection. Once a new history version of an offer is created, there is only one more operation that you need to do. As before, add the offerHistoryId document in your offerId collection, add the same object in your offers collection, but in this case you need to remove the older version of the offer from the offers collection.