If you have to fill or change your class data other than by standard object filer or SQL filer
you also have to get your indexes in line with your data.
Rebuild Index might be time consuming exercise eventually blocking access at all.
I just detected ##class(%Library.Storage).%ValidateIndices()
Not really new, but in 2015.1.1 , 2016.2.1 there was not a single character of documentation to it.
Now I see on latest
%ValidateIndices() - Validates indices for a class
- Optional. "" to check all indices, or specify a $list of index names to check. Default=""
- Optional. If true, correct any errors found. Default=0
- Optional. Default = 1 0 - No locking is performed at all 1 - Shared locking as each row is checked 2 - exclusive lock on entire table for duration of the run
- Optional. If true, parts of %ValidateIndices will use parallel processing when possible. Default=1
- Status Code
- Do $SYSTEM.OBJ.ValidateIndices("Sample.Person","",1,2)
- Do $SYSTEM.OBJ.ValidateIndices("Sample.Company",$lb("NameIdx"),1,1)
Indices may also be validated by calling the class method $SYSTEM.OBJ.ValidateIndices(classname,idxList,autoCorrect,lockOption).
There is one main difference between validating indices through $SYSTEM.OBJ.ValidateIndices() and ##class(classname).%ValidateIndices().
$SYSTEM.OBJ.ValidateIndices() will validate the indices for a table, and it will also validate any indices in collection child tables for that table.
When using ##class(classname).%ValidateIndices(), collection child table indices must be checked with separate calls.
Also, when calling $SYSTEM.OBJ.ValidateIndices(), multiProcess default is 0. When calling ##class(classname).%ValidateIndices(), multiProcess default is 1.
Is this what I liked to interpret:
The method that removes dead entries and adds missing ones it if I set autoCorrect to 1.
The Index Repair ?
Has anyone ever tried it ?