With the help of Stephen Bohlen (author of "Summer of NHibernate" screencast series), we were able to get to the bottom of this issue yesterday. Noting that the above-mentioned test fails when run normally but passes when stepped through in debug mode, Stephen suggested that I insert a 10 second delay "Thread.Delay(10000)" immediately after persisting the record PersistEntity(listing). With this delay in place, the test passed.
But when I set the delay to just 1 second the test failed. The minimum I was able to set the delay and pass the test was 3 seconds. The question was then, "why is the delay necessary for the test to pass?" In other words, why do we need to delay a few seconds after persisting an entity before we attempt to retrieve it using full-text- search? Then it dawned on me. Here is what I wrote to Steven yesterday: "A thought occurred to me that the reason a delay is necessary for full-text-search is because it takes a few seconds for the text to be fully parsed and indexed. A FTS query works against the FTS index and not the actual text in the field. If you add a record and then immediately search the index, the record is not found because that entry has not yet been indexed. Does that make sense?" Stephen replied, "Yes, actually that makes 1000% sense and is probably what's happening here. You can verify this by performing the retrieval against that actual text in the field (e.g., via a direct- select-query) instead of using the FTS indexer and see if that results in a success. It would also explain why either yourself in the debugger or the Thread.Sleep(...) call would result in a success: either would give the FTS indexing engine enough time to add the new record to the index. Do a bit more testing to see if that's definitely the cause, but my initial guess would be that you are onto something there with that explanation." As Stephen suggested, I did another test where I performed the retrieval against the actual text in the field: "Select * from Listings where Description LIKE '%men%'" and the test passed without using a delay. This indicates that testing full-text-search queries requires a slyghtly different approach than testing standard SQL queries in light of the fact that the FTS functions FREETEXT and CONTAINS don't query the actual text that you just inserted but rather the index. And if you don't give the DBMS enough time to parse and index the text before attemption retrieval using FREETEXT or CONTAINS, then the test will fail. Even in my test case where I inserted just one short sentence, a few second delay was necessary because that's how long it took the system to build the index for that short sentence even on my smokin' fast computer. At this point, Stephen and I see no way to avoid using the Thread.Delay (xxxx) when testing insertion and retrieval of FTS-indexed records using FTS methods. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "nhusers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/nhusers?hl=en -~----------~----~----~----~------~----~------~--~---
