2

I've read through this excellent feedback on Azure Search. However, I have to be a bit more explicit in questioning one the answers to question #1 from that list...

...When you index data, it is not available for querying immediately.

...Currently there is no mechanism to control concurrent updates to the same document in an index.

Eventual consistency is fine - I perform a few updates and eventually I will see my updates on read/query.

However, no guarantee on ordering of updates is really problematic. Perhaps I'm misunderstanding Let's assume this basic scenario:

1) update index entry E.fieldX w/ foo at time 12:00:01
2) update index entry E.fieldX w/ bar at time 12:00:02

From what I gather, it's entirely possible that E.fieldX will contain "foo" after all updates have been processed?

If that is true, it seems to severely limit the applicability of this product.

Community
  • 1
  • 1
Jmoney38
  • 3,096
  • 2
  • 25
  • 26

2 Answers2

3

Currently, Azure Search does not provide document-level optimistic concurrency, primarily because overwhelming majority of scenarios don't require it. Please vote for External Version UserVoice suggestion to help us prioritize this ask.

One way to manage data ingress concurrency today is to use Azure Search indexers. Indexers guarantee that they will process only the current version of a source document at each point of time, removing potential for races.

Eugene Shvets
  • 4,561
  • 13
  • 19
  • But there's a difference between ordering of writes and optimistic concurrency. I guess you're saying no to both, and that OCC is an eventual solution if enough customers vote for it? – Jmoney38 Nov 21 '16 at 22:59
  • Yes. If we expose document versions, it will probably be done as monotonically increasing versions usable for write ordering. – Eugene Shvets Nov 21 '16 at 23:15
1

Ordering is unknown if you issue multiple concurrent requests, since you cannot predict in which order they'll reach the server.

If you issue indexing batches in sequence (that is, start the second batch only after you saw an ACK from the service from the first batch) you shouldn't see reordering.

Pablo Castro
  • 1,644
  • 11
  • 11