Seems like the overwrite=false flag is purely for better performance whenever you KNOW that you are indexing docs that have not been indexed before. So it would be easy to deprecate the feature and let it always be true if that plays better with updateLog?
-- Jan Høydahl, search solution architect Cominvent AS - www.cominvent.com > 18. sep. 2018 kl. 14:02 skrev David Smiley <[email protected]>: > > Do you mean write new code for adding a feature for _version_ to behave like > overwrite=false? I suppose anything's possible with new code, though I'm not > sure if it fits semantically since the result of overwrite=false is the > possibility of a duplicated document -- something otherwise impossible. > > I don't really like the very existence of overwrite=false and don't want us > to take on the burdens of supporting it in dubious cases, like having an > updateLog. > > On Tue, Sep 18, 2018 at 5:09 AM Jan Høydahl <[email protected] > <mailto:[email protected]>> wrote: > Can't the overwrite=false logic be replaced with some logic using the > _version_ support, which would also support updateLog? I know you can provide > a specific version in the update and it will not update if the index already > contains a newer version, but I'm not sure if there is a _version_==null kind > of feature? > > -- > Jan Høydahl, search solution architect > Cominvent AS - www.cominvent.com <http://www.cominvent.com/> > >> 18. sep. 2018 kl. 06:20 skrev David Smiley <[email protected] >> <mailto:[email protected]>>: >> >> Is <add overwrite=false> supported when there is an UpdateLog? Perhaps >> only when you are darned sure the doc is in fact uniuqe? Maybe we should >> throw an exception if you even try at all with an UpdateLog? >> >> Context: I'm working with Moshe, a contributor, on doc updates for nested >> docs. It's all very much WIP with TODOs but nonetheless ConvertedLegacyTest >> failed due to some oddity. It turns out this ancient test deliberately adds >> docs with overwrite=false that already exist by the same ID. Youch! This >> test very much pre-dated the UpdateLog, but at some point the UpdateLog >> ended up in the default config thus this test ended up using it. It >> *appears* to be accidental luck that the test hasn't been failing -- i.e. I >> doubt this situation above was deliberately made to work. We're fiddling >> with some related code and now it fails. >> >> I'm inclined to think the test is broken by virtue of it using a config with >> an UpdateLog -- something it wasn't originally designed for. >> -- >> Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker >> LinkedIn: http://linkedin.com/in/davidwsmiley >> <http://linkedin.com/in/davidwsmiley> | Book: >> http://www.solrenterprisesearchserver.com >> <http://www.solrenterprisesearchserver.com/> > -- > Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker > LinkedIn: http://linkedin.com/in/davidwsmiley > <http://linkedin.com/in/davidwsmiley> | Book: > http://www.solrenterprisesearchserver.com > <http://www.solrenterprisesearchserver.com/>
