firetable metadata organization advice

[weidongguo]

When we set up firetable for a Firebase project and create a table, we start seeing metadata collections (e.g. _FIRETABLE_, _FT_USERS) created in the top level of Firestore. These metadata are mixed up with existing data generated by the users of the app

1. Is there a way to group the metadata up (e.g. Firetable/firetable/___)?, so then all the metadata along with the data entered through the Firetable CMS is organized into one spot.

2. If the answer is no for 1), then for separation of concern, do you recommend creating a separate Firestore instance (i.e. separate Firebase project as Firebase doesn't support more than one firestore instances right now) for data entered through the Firetable CMS?

3. any other suggestions in separating the data generated by Firetable CMS and data generated by users through the app?

[shamsmosowi]

Hi @weidongguo , we are looking into implementing your 1st suggestion, we'll probably move all the firetable metadata inside the FIRETABLE collection

[tv42]

I think putting Firetable things in the same database as the actual data risks having them show up in collection group queries. Relying on field&sub-collection names to be unique sounds like a ticking time bomb.

https://firebase.googleblog.com/2019/06/understanding-collection-group-queries.html

[notsidney]

Hey @weidongguo, as part of the v2.0.0 release: config is now stored in one top-level collection, _rowy_. You’ll need to perform a migration since this a breaking change, but we have a setup UI to copy the old config to this new location. After that, you can delete any top-level collections from before.

You can migrate the latest version of Rowy by using this easy deploy link on your Firestore project: rowy.app/deploy. Try it out and we would love to get your feedback on Discord 🙏

@tv42 Thanks for pointing this out. Firebase’s implementation for collection group queries is odd in that regard and it’s probably a limitation of the internal Firestore architecture. The blog post has some suggestions that would work around this problem. If this becomes a bigger issue, we could rename the subcollections to have _rowy_ prefixes as well, but for now I’ll close this issue.