[IMPORTANT] IBM confirms fielded FTSearch limitation

We figured out that FTSearches does not always return all possible documents. It occurs when you use the wildcard operators * and/or ? in a fielded query. But only when the word with the wildcard results in more than 1000 possible combinations. Like the SQL statement:

SELECT Table.Field FROM Table WHERE Table.Field Like ‘Phrase’ GROUP BY Table.Field;

If this would return more than 1000 the problem exists. We are not sure if the the result is grouped. From our testing we would say yes. So the combinations 1001 to n are not found with FTSearch.

This leads to really strange effects. Let’s say you have two documents where the field TF contains the values

Doc A: TF = “Data0000 TESTDOC”

Doc B: TF = “Data1000 TESTDOC”

then you have also 2000 documents where the TF value is

Doc 1: TF = “Data0000”

Doc 2: TF = “Data0001”

Doc 3: TF = “Data0002”

Doc 2000: TF = “Data1999”

If you search with the query

query = "FIELD TF CONTAINS (Data* AND TESTDOC)

you should get 2 documents returned but you just get 1. You just find doc A. The reason is that the query part “Data*” has more than 1000 combinations and the combination “Data1000” of Doc B is after the limit of 1000.

We were doing hundreds of tests. This effects all R6.x versions.

Following the message from IBM:

Full Text and View searches fail to find some documents when the search criteria uses the FIELD operator and Wildcard (* or ?).

The solution is to update our underlying GTR engine. This is risky to do in an MR as it may introduce regressions.

Historically upgrading the GTR engine has exposed us to regressions.

We recommend an interim solution of views that key off required fields, until a new GTR engine is put in a later feature release.

We hope that we can solve this problem in Domino Notes version 7.x

Subject: Interesting… I’ve also noticed that the new GTR in ND6…

…seems to execute FIELD-specific searches slower than it did in R5 (5.0.11 to be exact). I’m still researching the issue and will post an update later (including progress with Lotus Support, if any).

I can definitely understand IBM’s hesitance to try to fix this right away. GTR “upgrades” have been iffy, at best – the fact that you couldn’t search using a negative number until 6.5.2 was a show-stopper for my company.

Subject: Also beaware of “too-short-searchstring” limitation when using wioldcard char *

Somewhere I read that the search engine yield unpredictable results if your searchstring is less than 3 char long