Unusual non 1 or -1 values for MongoDB indexes - mongodb

Question

I tried to create index using
db.collection_name.createIndex({"field_name":1})
Then when I'm calling getIndexes() it gives me following results
{
"v" : 2,
"key" : {
"field_name" : 1.0
},
"name" : "field_name_1",
"ns" : "dbname.collection_name"
}
So I wonder why is it floating point "field_name" : 1.0 now? Is it bad? Should I even worry about it? Any way to make it exactly 1?
And out of curiosity: I've noticed I can even successfully call it that way:
db.collection_name.createIndex({"another_field_name":12345})
without it producing any errors. I wonder what's happening in this case.

Answer 1

Your question is actually a couple of questions, but the first does have a brief answer
Q: "Why am I getting a floating point?"
A: Because you are using robomongo, and the interface simply displays the supplied Number type in that way. The mongo shell actually displays this differently
And the second:
Q: "Why can I use 12345 as a value instead of just 1 or -1?"
A: Because its still actually numeric and valid. All MongoDB cares about here is "positive" or "negative". So where "positive" issuing a query that used the index would sort "ascending" by default. But you still would need to supply 1 or -1 to a specific .sort(), since that is all that would be valid.
To demonstrate the latter case, insert some data into your collection:
db.collection_name.insertMany(
[5,1,3].map( v => ({ another_field_name: v }) )
)
And create your index:
db.collection_name.createIndex({ "another_field_name": 12345 })
If you issue a range query, the "ascending" order is used by the "positive" value:
db.collection_name.find({ "another_field_name": { "$gt": 0 } },{ "_id": 0 })
{ "another_field_name" : 1.0 }
{ "another_field_name" : 3.0 }
{ "another_field_name" : 5.0 }
This shows the order of the index being applied even though the actual insertion of values was in a different order. So the index is being clearly applied here.
If you tried to explicitly .sort() using any other value than 1 or -1 on this type of index, then that would produce an error. But of course this would result in "ascending" or "descending" sort respectively, as MongoDB will happily reverse the order of traversal for the index.
If you removed the index and created one using a "negative" value:
db.collection_name.dropIndexes();
db.collection_name.createIndex({ "another_field_name": -54321 });
And then issued the same query:
db.collection_name.find({ "another_field_name": { "$gt": 0 } },{ "_id": 0 })
{ "another_field_name" : 5.0 }
{ "another_field_name" : 3.0 }
{ "another_field_name" : 1.0 }
Then the "descending" order is applied because that is essentially what you told it to do in default handling.
Is this good or bad overall? From a storage point of view it really does not matter, as no matter the actual value presented a BSON Double is still a BSON Double.
You could alternately use NumberInt for a specific 32-bit value as opposed to a 64-bit value as specified in BSON Types, but again the value being 1 or 65,000 or in the reverse as -1 or -65,000 does not change the allocated storage or the basic handling of where it is "postive" or "negative".
For general readability and consistency with arguments to .sort() then as a "matter of opinion", using 1 and -1 is more consistently understood for it's intended purpose.
It is actually the "preferred" implementation as to the specification, and is somewhat echoed in the documentation ( though not to prominently ):
Some drivers may specify indexes, using NumberLong(1) rather than 1 as the specification. This does not have any affect on the resulting index.