#dominoforever | Product Ideas Portal

Welcome to the #dominoforever Product Ideas Forum! The place where you can submit product ideas and enhancement request. We encourage you to participate by voting on, commenting on, and creating new ideas. All new ideas will be evaluated by HCL Product Management & Engineering teams, and the next steps will be communicated. While not all submitted ideas will be executed upon, community feedback will play a key role in influencing which ideas are and when they will be implemented.

For more information and upcoming events around #dominoforever, please visit our Destination Domino Page

FTSearch should also search through the unindexed documents

In a database, in order to  find really all documents that match a query, our current approach is to execute an FTSearch, check the last indexed time, get a view of recently modified documents, and loop through them to find the rest, if any. IMHO this is the way that FTSearch should operate, logically, and intuitively. Some say that there are technical reasons why this is impossible (my idea on IdeaJam got voted down), but they hold no ground in my opinion: why should a programmer care if the Indexer has done its job or not? FTSearch is already very fast, and it would still be fast if it were completed by a simple search through the unindexed documents to add those missing as well as the deletetion stubs to remove those  that have recently been deleted.

  • Guest
  • Jul 25 2019
  • No Plans to Implement
  • Attach files
  • Guest commented
    13 Jan, 2020 06:10pm

     Splendid, thank you!

  • Guest commented
    13 Jan, 2020 05:15pm

    Ok, thank you.  We can work with that.   I created SPR JCUSBKSN4Z so you can track it.  At this point, targeting 11.0.1

  • Guest commented
    10 Jan, 2020 02:05pm

    Here's the error message we get:
    10/01/2020 14:57:56   Error full text indexing document NT00000000  (rc=3859) Database is currently being indexed by another process

  • Guest commented
    10 Jan, 2020 10:57am

     Thank you, we much appreciate your suggestion. We'll do some tests with our application, by calling UpdateFTIndex just before calling FTSearch. If there are serious problems, we'll open a case with support. This problem we already experienced in R8 or R9, see http://ideajam.net/IdeaJam/P/ij.nsf/0/C84C6E5E7D6DCF224A2579AB0060FE1F?OpenDocument . Now testing with the brand new V11. We're hopeful!

  • Guest commented
    9 Jan, 2020 06:36pm

    Ok, the problem statement behind the idea is that there are documents newly updated that have not been full text indexed yet.  And you have experienced difficulty keeping indexes current, though you haven't indicated how the "server complains heavily when the application requests the Indexer to be started too often".  There are calls update the full text index in every API we offer.  If those are not working, or you're persistently getting an error state, please open a case with support.  We'll fix it.  

  • Admin
    Thomas Hampel commented
    9 Jan, 2020 04:44pm

    This is provided by properly maintaining the FTIndex. please have a look at the DBMT documentation for refreshing an FTIndex on a regular basis.

  • Guest commented
    25 Jul, 2019 08:56pm

    Sorry, but that's just one of the many "technical reasons" that do not hold any ground IMHO. What you mention is what I simply call it bad maintenance. Of course there is an optimum for every database, and it could even be automatic.
    Our technical reason that this doesn't work for us is that the server complains heavily when the application requests the Indexer to be started too often, e.g. while it's already running. Therefore, unindexed documents are inherent to full-text indexing, there is no way to guarantee that the index is up to date.
    What is so wrong about the idea that FTSearch does what any nincompoop would assume it should do: search the flipping database (or view) and find all the documents matching a query? Or do you have any good logical reason for the behaviour you defend?

  • Guest commented
    25 Jul, 2019 08:08pm

    An FTSearch that fires against a database that has not been indexed in days will NOT perform.  And the streaming required without indexing is expensive and slow.  It is better to push unindexed documents into the index then do a regular FTSearch.  Then all other threads and users benefit.