Then that was probably a bug in 4.6. There's a lot of work that's been done since then, and distributed updates that are mixed like this are particularly "interesting".
So you should be able to count on this. One other possibility: Is it possible that this was a false failure in 4.6 and a commit happened between the original insert and the delete? Just askin'... Best, Erick On Wed, Nov 18, 2015 at 8:21 AM, Matteo Grolla <matteo.gro...@gmail.com> wrote: > Thanks Shawn, > I'm aware that solr isn't transactional and I don't need this property: > a single application is indexing. > With solr 4.6 I was noting a different behaviour, with 4.10 I'm observing > the desired one. > I'd like to know If I can count on this behaviour to be maintained by > successive solr version. > > 2015-11-18 16:51 GMT+01:00 Shawn Heisey <apa...@elyograg.org>: > >> On 11/18/2015 8:21 AM, Matteo Grolla wrote: >> > On Solr 4.10.3 I'm noting a different (desired) behaviour >> > >> > 1) add document x >> > 2) delete document x >> > 3) commit >> > >> > document x doesn't get indexed. >> >> If the last operation for document X is to delete it, then it will be >> gone after the commit and not searchable. >> >> Order of operations is critical, and it's important to realize that Solr >> is not transactional. With a relational database like MySQL, updates >> made by one client can be logically separate from updates made by >> another client. Solr (Lucene) does not have that logical separation. >> When a commit happens, no matter where the commit comes from, changes >> made by ALL clients before that commit will become visible. >> >> Thanks, >> Shawn >> >>
