Document in Collection doesn't show searching for Phone Number

Working with Data
1

When I query my database (stored in Atlas) using a user’s full name, it returns the expected result, but when I query using phone number, it returns nothing. This is only occurring for one (out of ~half a dozen) user.
For example,

db.callers.find({"fullName" : "John Doe"})

returns

{
   "fullName" : "John Doe",
   "phoneNo" : "07123456789"
}

but

db.callers.find({"phoneNo": "07123456789"})

returns nothing.
Am I missing something? The data definitely exists (as it is being returned by the first query). Could it be to do with the user’s specific phone number? If so, why?
Thanks

2

Hello @Ewan_Spence, welcome to the MongoDB community forum!

By looking at what you had posted it is difficult to say what the issue is. But, you can try to find the data type of the phoneNo field. The following aggregation query prints the data type of the field:

db.callers.aggregate([
  { $match: { fullName: "John Doe" } },
  { $addFields: { phoneDataType: { $type: "$phoneNo" } } }
])

As per your posted information it should return phoneDataType: "string". Let me know.

1 Like
3

Since the issue only happens for some, I would also verify the spelling of phoneNo for the documents that do not work. Being, schemaless, some documents might have phoneno or PhoneNo or any variation.

4

Yes, it returns the full document for John Doe, with “phoneDataType: “string”” at the end

5

All documents have been inserted the same way - using an API I built in JavaScript.
My current working theory is that something in the user’s phone number (it goes without saying that their real phone number is not ‘07123456789’, and that I cannot share their actual number) is triggering some mongo escape sequence that I don’t know about. That’s the only thing I can think that could be causing this.

6

One thing to check is for leading or trailing white spaces which sometimes are carried with cut-n-paste without being obvious.

Quotes are also problematic with cut-n-paste depending from where you cut and where you paste. If you look at the post in this thread sometimes the quotes are the modern matching quotes as in

or are the traditional quotes as in

I have also seen issues hard to visualize with uppercase o (O) and zero (0). Some fonts also make one (1) hard to distinguish from lowercase l.

One last thing I would check is the presence of an index with a specific collation. Partial indexes can also exhibit funny behaviour but since you find with phoneNo only, that should not be the case.

7

The first two issues I’m confident are not what is causing the problem - there are no white-spaces, nor copy-pastes, nor quotations in my queries.
The final point I’m not sure I understand, how would I go about checking that?

8

You can get the indexes of your collection with https://docs.mongodb.com/manual/reference/method/db.collection.getIndexes/.

Any indexes with particularities that might affects result will stand out compared to the others. I am not sure how they would look like but usually the output is verbose enough.

9

The only output I get from getIndexes is

[
	{
		"v" : 2,
		"key" : {
			"_id" : 1
		},
		"name" : "_id_",
		"ns" : "lktdb.callers"
	}
]

Which I assume is normal.

10

Please post a document which you could query without the problem.

11

The issue with this is that I’m querying phone numbers, and I don’t want to post that sensitive information online. The example I’m using in the question (John Doe, 07123456789) is not the real document, but I do have a document in the collection under the name John Doe (made for testing purposes) that I can query successfully.

12

Totally normal. You may exclude my index theory.

13

Still don’t have an answer for this - very perplexed as to what’s going on. The app is continuing to work for all other users, but the phone number in question still returns nothing.

14

The only last thing I could think of is that there is some non-visible characters like a backspace inside the phone number that are not copied with cut-n-paste. To see any non-visible characters you have to print the phone number in hexadecimal. The following should work:

15

If the issue is with some documents only, check what is the source of the document creation. Are there multiple sources of creating documents? What are these processes or applications?

Are these trouble documents still being created with new data in the collection? If not, you can think about how to fix the existing “bad” data.