fixed typo

[redabourial]

doc.id here should be doc._id .

What

There is a bug causing all added documents to not be tracked correctly and outputing " (utils.js:14) Document ID is undefined" for each added document to stdout.

Why

The code seems to work correctly without fixing this issue (aside from the outputs to stdout). but since it is a typo it probably has some side effects i'm not aware of.

[manueltimita]

This has been introduced in the pull request here: #177. In my opinion, that kind of change should have been accompanied by a test, especially since it is meant specifically to address an issue with a third-party library (Grapher), not an inherent issue with meteor-publish-composite. Personally, I'm advocating for reverting that pull request until we have a better understanding of it.

[UPDATE]
@StorytellerCZ I know you asked me to review that pull requests, but I didn't have the time. I reviewed it now and it only seemingly worked for the implementer because of the bug highlighted here. The problem with #177 is that const existingDoc = this.docHash[buildHashKey(collectionName, doc.id)] only seems to work because doc.id is undefined. Thus added will be executed unnecessarily, likely adding a large performance penalty.

For reference, here is the function whose call has been replaced by that call. Note that const existingDoc = this.docHash[buildHashKey(collectionName, id)] has been simply copied from there:

  _hasDocChanged (collectionName, id, doc) {
    const existingDoc = this.docHash[buildHashKey(collectionName, id)]

    if (!existingDoc) { return true }

    return Object.keys(doc).some(key => !isEqual(doc[key], existingDoc[key]))
  }

[UPDATE 2]
Created pull request #181 to revert #177, likely rendering this pull request (#180) unnecessary.

[UPDATE 3]
There is an ongoing conversation under #177.

[redabourial]

superseeded by #181 and the excellent work of @manueltimita

[manueltimita]

Thanks @redabourial - check out #182