makeKeyGeneric supports $[]

[kfritsch]

This change would let simple-schema support $[<identifier>] as update modifier as requested in longshotlabs/simpl-schema#378. This is the implementation I proposed in this issue.

• makeKeyGeneric now makes any $[<identifier>] notation generic as well

In case this might cause unwanted behavior for other use cases it might be more wise to add a separate function. Something like:

static generalizePositionalOperator(key) {
    if (typeof key !== 'string') return null;
    return key.replace(/\.([0-9]+|\$\[.*\])(?=\.|$)/g, '.$');
  }

[kfritsch]

@aldeed

[kfritsch]

Made the identifier matching regex more restrictive by only matching character sequences. Im not entirely sure what mongo allows as part of an identifier but since its seems resonable to only use letters there I thought it would be wiser to be more restrictive.

[aldeed]

@kfritsch Thank you for working on this. It looks like your solution is probably mostly correct, but given the enormous role this function plays in simpl-schema code, you should add a couple tests to prove it works correctly for both $[] and $[<identifier>] at various levels of nesting. The existing test is here: https://github.com/longshotlabs/node-mongo-object/blob/master/lib/mongo-object.test.js#L203-L206

Regarding the identifier piece, the docs say this here:

The <identifier> must begin with a lowercase letter and contain only alphanumeric characters.

So it also needs to handle numbers. But for our purposes, is there any reason to be restrictive? Wouldn't it work to say: $[ (0 or more characters) ]

This would make it future proof if Mongo changes. Either way having some more good test cases in the test file, with various identifiers, will add confidence that this is being done correctly.

[kfritsch]

According to the docs mongodb is not very restrictive concerning their field names. It seems like a nested field could very well have the name "$[]" or "$[elem]". Isn't there already a problem with numbers as positional index. Consider an array with nested documents, where the nested documents contain numeric fields. collection.find({"foos.5": {"$exists": true}}) could either mean the 6th element or all nested documents that contain the field "5".

There is already a feature request for mongo to escape certain characters.

In any case. I made the identifier less restrictive and added some tests for correct uses of the positional operator neglecting very odd field name usages. I also squashed the commits and made the message more meaningful.

[aldeed]

@kfritsch

It seems like a nested field could very well have the name "$[]" or "$[elem]".

I don't think so because the two rules as far as I remember are "no periods" and "can't start with a dollar sign"

It is true that foos.5 could be referring to a field with the name "5", but as far as I remember simpl-schema handles this by checking whether foos is an array or object in the schema. That doesn't help in this package, but the current way it works has been fine for years. Basically most people follow the simple guideline of avoiding using a solely numeric key.

[aldeed]

One more thing and then this should be good