I think you're pretty on-track. My suggestion though would be to move this to a filter query. This still leaves you with the problem of having to remember to change the query logic later, but at least makes this inexpensive after the first go.
And you probably want something like: fq=is_deleted_b_ns:false OR (*:* -is_deleted_b_ns:[* TO *]) The original form would take the set of all docs for which the value was "false" and remove from it all the docs that have any value in that field which is much different as some of those docs potentially have the field set to false. Solr/Lucene queries are not strict Boolean logic, see Chris Hostetter's excellent article: https://lucidworks.com/blog/2011/12/28/why-not-and-or-and-not/ Hmm, wait. Isn't this really "fq=-is_delete_b_ns:true"? (note there is special logic to handle "pure negative" filter queries). This assumes that all cases of the field being absent mean the doc is _not_ deleted... Best, Erick On Thu, May 19, 2016 at 8:17 AM, Sebastian Riemer <s.rie...@littera.eu> wrote: > Hi, > > > > I’ve introduced a new boolean field “is_deleted_b_ns” on my objects which I > index with Solr. I am using dynamic field definitions (“b” indicating > Boolean, “ns” for “not stored”). > > > > Since the field did not exist while the index was built, none of my > documents currently has that field indexed. > > > > My queries from now on must always include this new boolean field: either > they ask the index is_deleted_b_ns:false or is_deleted_b_ns:true. However > since the field is not yet indexed both queries return 0 results. > > > > I see two ways I could go from here: > > 1) Either rebuild the whole index so that all documents index this > newly added field as well (time consuming) and then above queries will > return the expected results. > > 2) I think I could ease my query in the way of OR combining: > is_deleted_b_ns:false with -is_deleted_b_ns:[* TO *] > > That would mean “give me the documents where the flag is false or where it > does not exist at all” > > > > Doing 1) is ok for now since this is a big change and we’re not in > production yet. Doing 2) feels kind of bad since I don’t know if it’s a big > performance hit. Also I don’t like it since it seems like I react to the > current state of the index in my program code - someday the index will be up > to date again and then I’d have this broader query logic in my program which > is not needed anymore. > > > > However 1) will be a problem when we are in production someday. Sure, we > won’t have changes that big all time to the index schema but one never > knows. > > > > What’s your opinion on this? May be there is another option as well? > > > > Best regards, > > Sebastian > > > > Mit freundlichen Grüßen > > Sebastian Riemer, BSc > > > > > > > LITTERA Software & Consulting GmbH > > A-6060 Hall i.T., Haller Au 19a > > Telefon: +43(0) 50 765 000, Fax: +43(0) 50 765 118 > > Sitz: Hall i.T., eingetragen beim Handelsgericht Innsbruck, > Firmenbuch-Nr. FN 295807k, geschäftsführender Gesellschafter: Albert > Unterkircher > > > > D-80637 München, Landshuter Allee 8-10 > Telefon: +49(0) 89 919 29 122, Fax: +49(0) 89 919 29 123 > > Sitz: München, eingetragen beim Amtsgericht München > unter HRB 103698, Geschäftsführer: Albert Unterkircher > > E-Mail: off...@littera.eu > Homepage: www.littera.eu > > > > Diese Nachricht kann vertrauliche, nicht für die Veröffentlichung bestimmte > und/oder rechtlich geschützte Informationen enthalten. Falls Sie nicht der > beabsichtigte Empfänger sind, beachten Sie bitte, dass jegliche > Veröffentlichung, Verbreitung oder Vervielfältigung dieser Nachricht > strengstens untersagt ist. Sollten Sie diese Nachricht irrtümlich erhalten > haben, informieren Sie bitte sofort den Absender durch Anruf oder > Rücksendung der Nachricht und vernichten Sie diese. > > This communication may contain information that is legally privileged, > confidential or exempt from disclosure. If you are not the intended > recipient, please note that any dissemination, distribution, or copying of > this communication is strictly prohibited. Anyone who receives this message > in error should notify the sender immediately by telephone or by return > e-mail and delete this communication entirely from his or her computer. > >
