Support for nested Collections / SubCollections?

[sceee]

Are Subcollections supported with mock_cloud_firestore?

As an example, in Firestore, I have the following collection: /maincollection/123/subcollection/456

Does mock_cloud_firestore work with such subcollections?

I tried to nest these in the source the following way but it does not work:

{
  "maincollection": {
      "1": {
         "abc": "xyz,
         "subcollection": {
            "999": {
               "example": "ex"
            }
         }
      }
   }
}

Also, how does mock_cloud_firestore support map fields of a document compared to subcollections?
How would they be represented in the JSON?

[ozanturksever]

I will look into this in next week, in the meantime if you can write a failing test, that will be helpful Thanks.

On Wed, Jul 3, 2019, 9:51 AM sceee [email protected] wrote:

Are Subcollections supported with mock_cloud_firestore?

As an example, in Firestore, I have the following collection: /maincollection/123/subcollection/456

Does mock_cloud_firestore work with such subcollections?

I tried to nest these in the source the following way but it does not work:

{ "maincollection": { "abc": "xyz, "subcollection": { "999": { "example": "ex" } } } }

Also, how does mock_cloud_firestore support map fields of a document compared to subcollections? How would they be represented in the JSON?

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/ozanturksever/mock_cloud_firestore/issues/10?email_source=notifications&email_token=AADK7T5HRJAWQNFLZFRENK3P5TKIXA5CNFSM4H5HYIS2YY3PNVWWK3TUL52HS4DFUVEXG43VMWVGG33NNVSW45C7NFSM4G5F4HLQ, or mute the thread https://github.com/notifications/unsubscribe-auth/AADK7T56TVWRINP74NGDGMTP5TKIXANCNFSM4H5HYISQ .

[sceee]

@ozanturksever sorry, I did not find the time until now. I could write a test - the question is how the data structure should look like.

Is the above data structure fine? I don't think it can be used exactly like this because this would mean there is no way to differentiate between subcollections and map fields.

Do you have an idea how to solve this differentiation? We could just introduce a kind of annotation "type" field or something like this that describes the type of the field (=subcollection or map).

[tresheffron]

I was working on this very problem but don't have a pull request yet. Hope to be back on it this week.

Also, open to any discussion before I try to finalize it. In my version, if it reads it as a map, it'll try to pull it in both as a map field and a collection, per your point @sceee about not being able to tell the difference. This approach doesn't fail any existing tests and allows the new tests to pass but it does feel a little clumsy. For mocking purposes, I think it works because you will be testing for a collection processing correctly or a map field processing correctly, and the other will be ignored.

  test('get sub-collection from document', () {
    MockCollectionReference col = mcf.collection("projects");
    expect(col, isNotNull);
    MockDocumentReference doc = col.document("1");
    expect(doc, isNotNull);

    CollectionReference cr = doc.collection("tasks");
    expect(cr, isNotNull);
    Stream<QuerySnapshot> qs = cr.snapshots();
    expect(qs, isNotNull);
  });

for this data sample:

"projects": {
    "1": {
      "id": "1",
      "title": "test project 1",
      "tasks": {
        "101": {
          "id": "101",
          "taskId": "1",
          "projectPriority": true
        },
        "102": {
          "id": "102",
          "taskId": "2",
          "projectPriority": false
        }
      }
    },

[ozanturksever]

sorry can't look into this quickly, i am on the road for a few days. will look as soon as got the time.

[diegoveloper]

any update about this ?

[ozanturksever]

merged https://github.com/ozanturksever/mock_cloud_firestore/pull/13

so the issue is, how to distinguish sub-collection from map. do you guys prefer a prefix like ">tasks" or not?