Ravendb Consulta Resultados correctos después del segundo intento

Question

Cuando comienza mi C#, WPF UI, una de las pestañas llama a este código al cargar. Los datos más recientes que se muestran son 11-FEB-2012, a pesar de que hay instalaciones documentos superiores a 15-FEB-2012. Cuando presiono el botón de actualización, se llama a este mismo código exacto, solo esta vez se muestran los resultados más recientes. ¿Cómo puede el mismo código producir dos resultados diferentes?

IQueryable<EntityBase> installationSummaries =
  QueryAndSetEtags(session => session.Query<InstallationSummary>()
  .Include(x => x.ApplicationServerId)
  .Include(x => x.ApplicationWithOverrideVariableGroup.ApplicationId)
  .Include(x => x.ApplicationWithOverrideVariableGroup.CustomVariableGroupId)
  .OrderByDescending(summary => summary.InstallationStart)
  .Take(numberToRetrieve));

Nota: Tengo exactamente el mismo problema con otra consulta. Parece que no me he consultado en mucho tiempo, obtengo los resultados incorrectos. Si vuelvo a preguntar justo después de hacerlo, obtengo los resultados correctos. Me pregunto si tengo que crear un índice. Hay más de 10,000 instalaciones documentales, y el rendimiento está bien. Es la precisión con la que tengo problemas.

Answer 1

Sounds like a stale index issue. Try to add this line and see if that helps

.Customize(x => x.WaitForNonStaleResultsAsOnNow())

Update: It is better to use WaitForNonStaleResultsAsOnNow() than WaitForNonStaleResults()

Edit: Why is that?
The reason is, that your query will create a temporary index that automatically will be deleted after some time of inactivity. Further, they will not survive a restart of RavenDB. Now you have a few option:

• promote the index to be permanent using the management studio

• create an index within your application and use that index when querying

• wait for raven to self optimize itself and promote the index automatically (this will only happen if the query will be run often enough, which seems unlikely in your case)

• use the .WaitForNonStaleResuls() option as outlined above (this is worst because it can have a very negative impact on application performance and there's no need to because the other options are much better)