Thanks Erik,
I observed the wrong behaviour on 4.6 in a controlled environment with
a very simple test case, so It's was probably a bug (or I was drunk ;-) )
Really thanks again!!!
2015-11-18 17:40 GMT+01:00 Erick Erickson <erickerick...@gmail.com>:
> 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
> >>
> >>
>
