#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

Easier way of fixing UNK table problem (FT index thinks field is different type)

Example:

Create a field (Number), and create-save a document with that field set.

Then create FT index for database

Then change field type from Number to text, create a new doc & save

(easily done when a field looks like it can be numeric but letters need to be added eg some unique key etc)

You can no longer search on that field because the UNK table has noted it as numeric.

 

Correcting this involves admin client or making a new copy of the database.. very messy, especially with large databases.

 

Can we have a better way of fixing this ?

  • Guest
  • Jul 19 2018
  • Needs review
  • Attach files
  • Guest commented
    24 Aug 10:33pm
  • Guest commented
    20 Jan 03:40pm

    Adding more information at the request of John Curtis
    https://twitter.com/john_d_curtis_/status/1351672385984987139

    The specific use case that we struggle with is date fields. We routinely stamp workflow related dates on documents e.g.status_100_dt = 20/1/2021

    Sometimes we need to set these dates to null if a document is reverted to the previous stage in the workflow. We would do this by setting status_100_dt = ""

    The problem is that if we make a new copy or replica of the application it will generate a new UNK table.

    In doing so the document where status_100_dt = "" may be used and then the UNK permanently flags this field as a text field FOR ALL INSTANCES.

    This means that the field status_100_dt can no longer be used as a date field in Full Text searches. As the UNK table is built based on NoteID and the NoteID varies between repicas / copies the UNK table will also vary between servers / replicas and copies

    It is worth noting that this behaviour can mean that an application with a scripted FT search element may work well on one server and on another identical server it does not because the code throws an error when a "text" field is used with "date" field syntax.
    status_100_dt > today works on server A and on server B throws an Unexpected Error

    Fixing this is very difficult. The data must be fixed and then the http task dropped ( our experience ) and then the application compacted.

    It is also very difficult to detect the problem in the first place, it would be great if we could see and alter the UNK table.

  • Guest commented
    19 Jan 07:47am

    VOLT introduced a FT search in version 1.0.2 - I'm seeing this issue with a VOLT application however here we create a numeric, currency or date field and they are all seen as TEXT. Cant search for values between, less than or greater than.

  • Guest commented
    4 Aug, 2020 01:53pm

    SPR #CSAO9BFB84 is present for this issue.

  • Guest commented
    6 Jul, 2020 01:52pm

    We see this too but no, we have not yet created a ticket, Sean Cull

  • Admin
    Thomas Hampel commented
    21 Jul, 2018 02:13am

    Have you reported this behavior in a PMR ? if so can you provide the #?