Fix withRelated not always grouping properly for binary IDs

[6utt3rfly]

Introduction

When I was working with a larger dataset that uses binary IDs, I found that sometimes the 'withRelated' was returning incorrect results. The database queries were correct with retrieving the relationships, but they were being incorrectly assigned to the primary collection. In the end, I found that if I changed the grouping to convert Buffer types to strings, then all of my relationships were set correctly.

Motivation

This should be a minor, non-breaking change that only changes local behavior to the relationships eagerPair method.

Proposed solution

When grouping relationships and building the collection map, convert Buffer IDs to string keys

Current PR Issues

no known issues with making this change...

Alternatives considered

I debated using a local parse method in my model, but thought that this would fix it more at the source rather than requiring me to add a parse method to all of my models.

[ricardograca]

This looks simple enough but it needs tests to verify the correct behavior of the fix, and to ensure that this bug doesn't get introduced again in the future.

[6utt3rfly]

I actually wrote a unit test, but found that the problem was bigger than I initially thought... it basically boils down to code something like this:

a[new Buffer('93', 'hex')] = ['123'];
a[new Buffer('90', 'hex')] = ['456'];
console.log(a, Object.keys(a).length);

There are several places in the code where the ID is assumed to be used as a unique object key. However, with Buffers, this doesn't always work because they get converted to a string representation which may have collisions.

I now found that the collection _byId property also does this, so when I query and get back 2 distinct rows, it's treating it as a single result.

I could go further and update this PR, but I thought I'd ask if you have any other thoughts first @ricardograca ?

[ricardograca]

I don't even understand how/why Buffers can be used as keys, so the fact that it more or less works at all is new to me.

You can do whatever you need to make your use case work as long as that doesn't break any of the existing functionality and tests are included. If the extra fixes you mention are not immediately being required to you it's OK if you don't fix them.

[6utt3rfly]

OK - I've added tests and fixes to collections. If you need more details or changes I'm happy to do so @ricardograca . Thanks for your quick responses!!

[ricardograca]

Just needs to address the two small issues I mentioned, and then I'll merge. I'm still waiting for another big PR to be merged, so this one will probably only go after that one: #1848.

[6utt3rfly]

Changes made - thanks for catching the debug:true which I forgot about! @ricardograca

[ricardograca]

Will merge after #1848 is merged, since I already spent a lot of time fixing merge conflicts in that one and if there are any in this afterwards they will certainly be easier to fix.