Node.js SDK FTS error "zero width assertions not allowed"

Node.js SDK
1

Using FTS, I attempting to apply a regex filter to locate exact matches to an exact value, OR, all that end with a regex of “.*”

Here is the pattern:
If no value is provided for the param “requestor” the regexp pattern should be “^exenv::user::.*" If a value is provided: "^exenv::user::123”

I have tried term, match, and now regexp and I am unable to affect the query in any way except to throw the error in the title of this topic, “zero width assertions not allowed”

The above regex pattern works beautifully in N1QL as follows:

SELECT META(dp).id, dp.* FROM dp dp
WHERE REGEX_LIKE(META(dp).id, “^exenv::user::.*$”)

I dont want to filter in this way as this term is but one of several, all of which perform as desired. This one just wont work.

Your help, as always, much appreciated.

JG

2

I think that your problem is not FTS but perhaps the model of your data.
If you have a type “user” you simply request this type to get all the “exenv user”.

But if you would like to get the exact value you can use the request :
SELECT META(dp).id, dp.* FROM dp use keys “exenv::user::123”

Good luck

3

@jejom43 - I appreciate your input. However, I detailed in my question why I needed an FTS solution and not a N1QL solution. Note my question included an acknowledgement I could use the N1QL query I illustrated, re-posted below:

This is actually more precise:
SELECT META(dp).id, dp.* FROM dp dp
WHERE REGEX_LIKE(META(dp).id, “^exenv::user::.*$”)

I noted the N1QL above worked sweetly for just that one predicate. The challenge is, there are at least 5-6 other dynamic query predicates, all of which worked exactly as desired. It is this one predicate I cannot get to cooperate. This is not ideal for N1QL.

I suspect FTS may be removing the “::”-separated segments of my document id’s. But I am unaware how to tell the FTS indexer to stop doing that.

4

You can post the FTS configuration ?

5

I have solved this issue. As I suspected, the native tokenization process was removing the colons.

The solution is to choose the FTS provided keyword analyzer which will treat the entire field input as a single token, including the special characters. The catch is, the query search term containing special characters indexed in that field must be escaped. To make the escaping easier to manage, set a pre-escaped, constant value as below:

// pre-escape the special characters - where the first string token is reserved for the subscriber_cd
// and the second for the provided user_id:
var requestor_filter: ‘%s\:\:user\:\:%s’;

//This is consumed by the node native util.format like so:

// complete the filter with the subscriber_cd and user_id:
var requestor_filter = util.format(tpl, subscriber_cd, user_id);
…
// add the filter to the query only if one was provided…
if (!_.isEmpty(user_id) {
qp.and(store.SearchQuery.term(options.requestor_filter).field(‘requestor’));
}

Test for a known matching user_id - items found - success
Test for a known non-matching user_id - no results - success
Test with no user_id provided - all users returned - success

1 Like