I just noticed what appears to be an issue with the FullTextQuery pagination. When I do:



I get back 97 results, even though a call to fullTextQuery.getResultSize() gives 125. If I set maxResults to 10, I get back 9 results. Is this something others have noticed?

Michael

hi, the boundaries of pagination work on the limits of the Lucene query, but when loading the entities it might happen to then discover that one or more of them are actually missing in the database: in this case it's silently skipped, as the database is supposed to be the one source to trust.
This might happen occasionally if you have the indexing configured "async", as the changes on the index could be visibile with some delay, but shouldn't happen often nor consistently.

If you experience consistent un-matches, most likely your index got out of synch from the database (restored a DB backup? run native SQL statements?), you can fix it by re-indexing.


this still is not totally right; are you speaking about the same query? if there are actually only 97 results out of 125, it should be fine to see just 97 in the case of setMaxResults(100), but you should see 10 in case of setMaxResults(10).

Sanne, thanks for your reply! Your explanation makes sense but, as you note, there is at least one anomaly. The same query with max-size = 10 returns 9 results. You may still be right. It may be that the ghost records aren't part of the first ten results (or only one of them is), but three are part of the first 100, somewhere in the set. I'll do some sleuthing with Luke and also do an index rebuild to see if anything changes. Thanks.

Michael

if you can reproduce the 9/10 results out of 97 issue, please open a JIRA about it, it shouldn't be hard to let it load some more results until the desired number of results are loaded. Just you'll have another issue in that case, which is the 10th element will likely be shown as the 1st of next page too. But it might be worth to discuss this with the other developers (i.e. a JIRA is needed to start this process)

Actually, it seems your theory was right, as reindexing the data fixed all issues! Thank you.

Michael