Full-text indexes are stored in folders (named after the .nsf file), that always reside in the same subfolder as the .nsf file itself. I propose to add an option to the server document, to place all full-text indexes into a dedicated location, similar to specifying the log path for transaction ...
At the moment the NotesDatabase class contains a method to create a new Full-Text Index, but only for a Local database, not for remote databases.
Getting access to the current Full-Text Index settings for a NotesDatabase object beyond a boolean that tells me if the db is indexed or ...
In addition to the old-style fulltext search tied to a view, it would be great to be able to fire a qeuery against the whole database, and be able to do it from anywhere (an outline-entry, a hotspot on a document, a "search bar" in a frameset).
Now with version ...
In XPages you can easily filter views by using an ftsearch.
Sadly after searching the result is not longer sorted (it sorted by notes-relevance, but nobody knows what that means).
Make this result sortable if the view columns are sortable, like in the notes client, where I can click ...
Allow for more control over the creation of a full text index for a database.
While an idea (linked above) already suggesting to redirect the full-text index creation for the whole server to a dedicated volume of (inexpensive and slow) disks, it does not go far enough to allow ...
The current all-or-none approach to full-text indexing causes unnecessary index size and performance considerations. I propose that a mechanism be implemented either/and by:
1. Dialog selection of fields to index
2. Special form field that specifies fields to index (eg: $FTIndexFields)