Nested documents

[knownasilya]

I noticed that there are buildReference on the relationships, and I tried to utilize those to do fetching of nested relationships but it's practically impossible because you needs ids to build out those references.

Here's one example:

  account = this.dataStore.createRecord('account', {
          ...input,
          id: username,
          username,
          createdAt: new Date(),
        });
        await account.save();

        const feedId = v4();
        const feed = this.dataStore.createRecord('feed', {
          id: feedId,
          title: 'Main Feed',
          description: 'Main feed',
          createdAt: new Date(),
          userId: this.session.user.uid,
        });

        await feed.save({
          adapterOptions: {
            buildReference: (db: Firestore) => {
              return collection(db, `accounts/${username}/feeds`);
            },
            include(batch: WriteBatch, db: Firestore) {
              batch.update(doc(db, `accounts/${username}`), {
                mainFeed: doc(db, `accounts/${username}/feeds/${feedId}`),
              });
            },
          },
        });

        await account.reload();

Notice how I couldn't do account.set('mainFeed', feed), because the reference there would be feed/{id} not accounts/{username}/feeds/{id}. This is even more prevalent when fetching, you need that context from the parent, and it's parent, etc.

Not sure what can be done.

[mikkopaderes]

This only works for simple use-cases where collections aren't nested. For complex ones like yours, you'll have to do a batch.set with merge option set to true for account to set the mainFeed via the adapterOptions.include in the account record.

[knownasilya]

What's the difference between batch.update and batch.set with merge: true? Seems like the same thing.

[mikkopaderes]

Hard to write something right now cause I'm on mobile but main difference is update only works if record exists already. Set can work even if record doesn't exist.

[mikkopaderes]

Actually, something I forgot. Have you tried to use buildReference from within belongsTo relationship of your mainFeed? This might actually work for your use-case.

[knownasilya]

How would I get the account id there?

[mikkopaderes]

Hmm, yeah. You can't at the moment. Maybe it's something I can try to expose in the next change.

[knownasilya]

Could nested documents be a feature, like a nested: true or nested: 'collectionName'. Maybe if we generated the ids in the adapter instead of auto generated by firestore?

[mikkopaderes]

Sorry, my goal in this project is not to provide any APIs to solve specific use-case (or at least keep it at the minimum). Instead, I just want to expose native Firestore API which will then be consumed by Ember Data. By going this route, I believe this would make the project have less maintenance as any API they make should just reflect immediately without us doing anything.

[knownasilya]

I get that, which I why I made this a discussion and not an issue.

[knownasilya]

Hum, totally ran into an issue. In the original example, when saving feed I have the include, which changes the mainFeed on account. The issue is if I later update my account:

account.setProperties({...data});
await account.save()

The account.mainFeed resets to feeds/{feedId}. So now I cannot use save() without specifying adapterOptions and include with the ref for mainFeed. This seems like a bug?

[mikkopaderes]

Yeah, this seems would likely be the case. Only if you override buildReference for belongsTo would you be able to set a custom collection path but as mentioned in the other thread, it doesn't fit your use-case because the account ID isn't exposed. This can be an enhancement from my side, but for the moment, you'll have to always have the adapterOptions to include the ref for mainFeed.

[knownasilya]

I think I could override save on the model and just pass it there? Seems like an elegant work-around.

[mikkopaderes]

With recent v3.1.0 release, your use-case should be satisfied now.

[knownasilya]

❤️

[knownasilya]

Hum, -firebase service was removed in v3. I was using that as the instantiated app if I needed to do something low-level, like getStorage(app) call. Can this be brought back? If not, is there another easy way to get the instantiated app?

[mikkopaderes]

Doing getStorage() will work even if you don't pass in app. But if you really need the app instance, then you import and call getApp()

[knownasilya]

How does that know about the config settings in config/environment.js?

[mikkopaderes]

App is already initialized by addon with your config here.

Now when calling getApp(), by default, it will fetch the default app which will be the one initialized above. Hence why we no longer need to have the Firebase service. This is also the case for things like getFirestore() and I believe is the same for getStorage() in which they would source out the default initialized app if you don't provide the app as a parameter.

[knownasilya]

Is there a way to preload relationships? I.e. async: false on a relationship and the include property (https://guides.emberjs.com/release/models/relationships/#toc_retrieving-related-records)?

[charlesfries]

Not currently AFAIK

[mikkopaderes]

As Charles said, no, it's not supported mainly because Firestore doesn't have native way to do it and I avoid adding sugar API as much as possible to keep maintenance easier.