Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

What is the scope of WaitForNonStaleResultsAsOfNow in RavenDB

If I run the following query on an existing RavenDB session:

var result = session.Query<Location>()
               .Customize(x => x.WaitForNonStaleResultsAsOfNow())
               .Where(l => l.Name = "Home" && !l.Deleted);

Which indexes does RavenDB wait for? My assumption is that it waits for all indexes to be up to date as of the time of the query; however does that mean that if there is only a single dynamic index on Location but 20 indexes on other tables, we are always waiting for 21 indexes to update?

Alternatively, am I misunderstanding the functionality of the method?

like image 988
Luke Merrett Avatar asked Mar 19 '23 10:03

Luke Merrett


1 Answers

If you were to watch the database communication during a query with Fiddler, or request the RavenQueryStatistics in your query like this...

RavenQueryStatistics stats;
var result = session.Query<Location>()
               .Customize(x => x.WaitForNonStaleResultsAsOfNow())
               .Statistics(out stats)
               .Where(l => l.Name = "Home" && !l.Deleted);

Then you would see properties like:

  • IsStale
  • Timestamp - when the query results were un-stale
  • IndexName - the index being queried
  • IndexTimestamp
  • IndexEtag - the document version corresponding to the last document updated in the index
  • Other things related to paging, etc.

This is the information that WaitFor(several variants) uses to determine if it should be satisfied or not.

So, the TL;DR answer is: just the one index that is being queried. It would be wasteful to check all of the indexes.

So for WaitForNonStaleResultsAsOfNow, it says OK, let's grab DateTime.Now, and then not return results until IndexTimestamp >= that date.

These WaitFor- methods are somewhat of an anti-pattern - you shouldn't rely on them exclusively to get consistent results, you should probably (in some cases, but not all) redesign your UI or your data model so that you are using Load/Store by document id (where ACID is guaranteed) where you need consistency.

But, looking at how it does it, you can see that it might be a better idea to use WaitForNonStaleResultsAsOfLastWrite, which causes the Raven client to note the last document E-Tag that it stored, and wait for that IndexETag to be incorporated in the index. This is especially true for a "Insert data, then show in updated grid" scenario. You don't need to wait for ALL the indexing to be done, you just want to be sure that the one thing you just inserted will appear.

like image 175
David Boike Avatar answered Apr 02 '23 21:04

David Boike