I've added automatic update of the FTIndex on search, when content has changed. There are rumours(?) on the web that FTSearch is evil, and that changes takes a long time to get into the index, even when running NotesDatabase.updateFTIndex.
I have never had those problems. It might be that it was something that was fixed in a previous version of the Domino server. I don't know.
To test how it works, change a document using the Notes client, then search for the changed value in the XPage.
Original post about the search interface demo
>> Download demoapp
12 comments:
that's one approach, but I'm not sure how the update task reacts if there are thousands of "updateFTIndex" requests comming into it's queue.
I tried something similar with a Java based server task about a year ago, and that caused various chrashes.
Another solution is to guarantee a timely update of the ftindex using a program document which executes "updall -F mydatabase.nsf" every 5 minutes or so.
That's fast enough in nearly all usecases. And if some users still complain, ask them how fast Google indexes changes to their website... that's longer than 5 minutes :-)
The only time there would occur thousands of updateFTIndex request would be if there were thousands of concurrent users querying at the exact same time/when a change occured, or if there are thousands of applications with changes.
The code checks for changes in content before it requests an update.
BTW. I think I forgot to remove an agent that tries to create the index, in the demoapp from the revisited-blogpost. I'll fix it when I get home from work.
The code I mentioned is the SSJS code :)
works weel
Nice demo! I like how you've implemented the templateSearch.
I'm working on extending/ changing the code a bit, so I can use it for multiple datatables on the same XPage. I've also implemented multi-page checkbox selections (with selection also being kept after resorting).
Looks like there's an error in the contentChangedSinceLastFTIndex function. The cutoff date to search for changes is now based on the lastModifiedDate and will only find documents created in the past five seconds.
Instead of using the variable lastFTIndexedAdjusted in the db.search call, it should use
lastFTIndexed.adjustTime(-5) in the db.search (or check for changes using db.getModifiedDocuments() ).
Mark
Another problem I found in the contentChangedSinceLastFTIndex function is that the following date objects comparison returns wrong results:
if( lastModifiedDate <= lastFTIndexedDate ){
I've gotten the right results using:
if (lastModifiedDate.getTime() <= lastFTIndexedDate.getTime() ){
Mark
I don't know why I checked for modified documents. I've changed the code to search for documents modified since the db was last FTIndexed - 5 seconds.
I haven't had any problems with the ftindexed vs lastupdated comparison, but just in case, I've changed the code to use the Java compareTo method. It's equal to using getTime.
The app is updated with the changes, so that any future downloaders will get the fix.
Thanks for your feedback. :)
In a recent project we are using FTSearch called by typeahed and filter-select-boxes to load documents into a datatable. Whenever a user saves a new document or edits certain fields, he expects that the document will show up in the datatable immediately after the save. We found that NotesDatabase.updateFTIndex did'nt seem to execute quite fast enough to include the document when returning to the datatable after a save.
So we created an agent, called on save of a document, that sends a console command telleing the server to update the FTIndex. The agent is ran on behalf of a user that is granted privileges to send console commands.
So far we haven't had any issues regarding performance due to this procedure, but then we're really not expecting thousands of concurrent updates.
sample code:
...
call NotesSession.Sendconsolecommand(db.Server, "load updall " + db.Filepath + " -F")
...
Sorry I keep complaining :-) , but I ran into another issue with the following code in the contentChangedSinceLastFTIndex function:
var query = '';
if( forms.length > 0 ){
query = 'Form="' + forms.join( '":"' ) + '"';
}
var col:NotesDocumentCollection = db.search( query, lastFTIndexedAdjusted );
If the forms array is empty, the query variable remains empty and the function performs a db.search() with an empty query. That always returns zero results. It will return the correct results if query defaults to "@All | @AllDescendants" if the forms array if empty.
Mark
Mark
Hi, I am using a view and also using free text search. Some of the columns can be sorted by the user. But sometimes after the sorting a column in a search result, the view display is a bit crazy. i.e. When you click on a row in a view to open the document a different document is being opened. In fact, I think its display not showing the correct data in rows after sorting a search result.
Has anyone encountered a similar problem? Any solutions? Thanks in advance. Thomas.
Are you using my search interface, or a standard view panel, with searching on sortable columns?
If you're using a standard view, I suggest posting the question on StackOverflow or the XPages forums. I haven't tested searching on sortable views, so I don't think I can be of much help.
I am using a standard view panel search. Thanks for the reply. Thomas.
Post a Comment