I am going through the docs to migrate our solution from v2 search_engine to v3.
Using v2 engine, we had a problem where we couldn’t find some users by looking for their given_name in the formalized fields, like in the following query:
q=given_name:(Linda*)&search_engine=v2
but we could overcome this issue using the following:
q=(given_name:(Linda*) OR user_metadata.given_name:(Linda*))&search_engine=v2
Previously, user_metadata was case insensitive and both queries below would produce the same results:
q=(given_name:(Linda*) OR user_metadata.given_name:(Linda*))&search_engine=v2
q=(given_name:(linda*) OR user_metadata.given_name:(linda*))&search_engine=v2
Unfortunately,
given the new v3 engine, we can’t have wildcard search on user_metadata anymore.
This wouldn’t be an issue if we didn’t have to use the user_metadata in the first place.
This is a blocker for us, because we can’t just use the query below to search for the user
q=given_name:(Linda*)&search_engine=v3
And the following query is not valid anymore
q=(given_name:(Linda*) OR user_metadata.given_name:(Linda*))&search_engine=v3
Another approach is using exact match like below:
q=(given_name:(Linda*) OR user_metadata.given_name:("Linda"))&search_engine=v3
But this still brings an issue with case sensitive user_metadata, where it matches Linda
but does not match linda
neither Lind*
The below is the exact result for Linda when returned:
{
"createdAt": "2018-01-17T16:22:18.119Z",
"emailAddress": "l.day@test.com",
"id": "auth0|5a5f783a7ad17571df2c9690",
"lastLoginAt": "2019-04-03T14:50:12.852Z",
"name": "Linda Day",
"pictureUrl": "https://s.gravatar.com/avatar/79edd9b68847d91252b2b7702081ae7b?s=480&r=pg&d=https%3A%2F%2Fcdn.auth0.com%2Favatars%2Fl.png",
"updatedAt": "2019-04-03T14:50:49.545Z",
"userIdentities": {
"hasAtLeastOneEmailIdentity": true,
"hasOnlyEmailIdentities": true,
"identities": [
{
"connection": "Username-Password-Authentication",
"isSocial": false,
"provider": "auth0",
"userId": "5a5f783a7ad17571df2c9690"
}
]
},
"userProfile": {
"assetPartyId": "12349",
"crmContactId": "1048113f-06f6-e711-80c5-005056825b41",
"dateOfBirth": "1980-04-04T00:00:00Z",
"firstName": "Linda",
"gender": null,
"lastName": "Day"
}
}
On the other hand,
the same issue does not happen to the following user:
{
"createdAt": "2019-04-16T14:41:58.809Z",
"emailAddress": "test.da@domain.org.uk",
"id": "waad|7fwsSHDpx3L2nZ7HhQLt3qlLeLMuh2n3XHLQ3vugxY8",
"lastLoginAt": "2019-04-16T15:27:31.657Z",
"name": "Test DA",
"pictureUrl": "https://s.gravatar.com/avatar/fbfb77b922b74be3325e27dc84492763?s=480&r=pg&d=https%3A%2F%2Fcdn.auth0.com%2Favatars%2Ftd.png",
"updatedAt": "2019-04-16T15:27:31.88Z",
"userIdentities": {
"hasAtLeastOneEmailIdentity": false,
"hasOnlyEmailIdentities": false,
"identities": [
{
"connection": "workwise-waad",
"isSocial": false,
"provider": "waad",
"userId": "7fwsSHDpx3L2nZ7HhQLt3qlLeLMuh2n3XHLQ3vugxY8"
}
]
},
"userProfile": {
"assetPartyId": null,
"crmContactId": null,
"dateOfBirth": null,
"firstName": "Test",
"gender": null,
"lastName": "DA"
}
}
Any of the following queries will be able to return the user above:
q=given_name:(test*)&search_engine=v3
q=given_name:(tes*)&search_engine=v3
q=given_name:(Test*)&search_engine=v3
q=given_name:(Tes*)&search_engine=v3
In summary,
The query q=given_name:(lind*)&search_engine=v3
does not work for all users, and this is preventing us from migrating to v3.