<!-- 
RSS generated by JIRA (9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66) at Thu Feb 08 03:04:25 UTC 2024

It is possible to restrict the fields that are returned in this document by specifying the 'field' parameter in your request.
For example, to request only the issue key and summary append 'field=key&field=summary' to the URL of your request.
-->
<rss version="0.92" >
<channel>
    <title>MongoDB Jira</title>
    <link>https://jira.mongodb.org</link>
    <description>This file is an XML representation of an issue</description>
    <language>en-us</language>    <build-info>
        <version>9.7.1</version>
        <build-number>970001</build-number>
        <build-date>13-04-2023</build-date>
    </build-info>


<item>
            <title>[SERVER-3918] make sparse indexes error out on {$exists: false} queries</title>
                <link>https://jira.mongodb.org/browse/SERVER-3918</link>
                <project id="10000" key="SERVER">Core Server</project>
                    <description>&lt;p&gt;When querying for documents in which a field does not exist, the optimiser will consider using a sparse index on that field, but this means that it will never find anything.&lt;/p&gt;

&lt;p&gt;&amp;gt; db.test.insert({});&lt;br/&gt;
&amp;gt; db.test.insert({});&lt;br/&gt;
&amp;gt; db.test.insert({});&lt;br/&gt;
&amp;gt; db.test.insert({});&lt;br/&gt;
&amp;gt; db.test.insert({});&lt;br/&gt;
&amp;gt; db.test.find({foo: {$exists: false}}).count();&lt;br/&gt;
5&lt;br/&gt;
&amp;gt; db.test.ensureIndex(&lt;/p&gt;
{foo: 1}
&lt;p&gt;, &lt;/p&gt;
{sparse: true, safe: true}
&lt;p&gt;);&lt;br/&gt;
&amp;gt; db.test.find({foo: {$exists: false}}).count();&lt;br/&gt;
0&lt;br/&gt;
&amp;gt; db.test.find({foo: {$exists: false}}).explain();&lt;br/&gt;
{&lt;br/&gt;
	&quot;cursor&quot; : &quot;BtreeCursor foo_1&quot;,&lt;br/&gt;
	&quot;nscanned&quot; : 0,&lt;br/&gt;
	&quot;nscannedObjects&quot; : 0,&lt;br/&gt;
	&quot;n&quot; : 0,&lt;br/&gt;
	&quot;millis&quot; : 0,&lt;br/&gt;
	&quot;nYields&quot; : 0,&lt;br/&gt;
	&quot;nChunkSkips&quot; : 0,&lt;br/&gt;
	&quot;isMultiKey&quot; : false,&lt;br/&gt;
	&quot;indexOnly&quot; : false,&lt;br/&gt;
	&quot;indexBounds&quot; : &lt;/p&gt;
{
		&quot;foo&quot; : [
			[
				null,
				null
			]
		]
	}
&lt;p&gt;}&lt;/p&gt;</description>
                <environment></environment>
        <key id="22631">SERVER-3918</key>
            <summary>make sparse indexes error out on {$exists: false} queries</summary>
                <type id="1" iconUrl="https://jira.mongodb.org/secure/viewavatar?size=xsmall&amp;avatarId=14703&amp;avatarType=issuetype">Bug</type>
                                            <priority id="4" iconUrl="https://jira.mongodb.org/images/icons/priorities/minor.svg">Minor - P4</priority>
                        <status id="6" iconUrl="https://jira.mongodb.org/images/icons/statuses/closed.png" description="The issue is considered finished, the resolution is correct. Issues which are closed can be reopened.">Closed</status>
                    <statusCategory id="3" key="done" colorName="success"/>
                                    <resolution id="9">Done</resolution>
                                        <assignee username="aaron">Aaron Staple</assignee>
                                    <reporter username="ben.spencer@digitalwindow.com">Ben Spencer</reporter>
                        <labels>
                    </labels>
                <created>Wed, 21 Sep 2011 11:42:31 +0000</created>
                <updated>Wed, 28 Oct 2015 04:26:22 +0000</updated>
                            <resolved>Sun, 27 May 2012 17:38:40 +0000</resolved>
                                    <version>2.0.0</version>
                                    <fixVersion>2.1.2</fixVersion>
                                    <component>Querying</component>
                                        <votes>12</votes>
                                    <watches>15</watches>
                                                                                                                <comments>
                            <comment id="137682" author="aaron" created="Thu, 28 Jun 2012 19:12:30 +0000"  >&lt;p&gt;Note that the currently implemented behavior (described in the existsa.js test) is to disallow a sparse index even if the field with the $exists:false predicate is not part of the index.  This behavior can be overridden by using a query hint to force use of a sparse index.&lt;/p&gt;</comment>
                            <comment id="123310" author="auto" created="Fri, 25 May 2012 23:45:06 +0000"  >&lt;p&gt;Author:&lt;/p&gt;
{u&apos;login&apos;: u&apos;astaple&apos;, u&apos;name&apos;: u&apos;Aaron&apos;, u&apos;email&apos;: u&apos;aaron@10gen.com&apos;}
&lt;p&gt;Message: &lt;a href=&quot;https://jira.mongodb.org/browse/SERVER-3918&quot; title=&quot;make sparse indexes error out on {$exists: false} queries&quot; class=&quot;issue-link&quot; data-issue-key=&quot;SERVER-3918&quot;&gt;&lt;del&gt;SERVER-3918&lt;/del&gt;&lt;/a&gt; Disallow sparse indexes for $exists:false queries.&lt;br/&gt;
Branch: master&lt;br/&gt;
&lt;a href=&quot;https://github.com/mongodb/mongo/commit/b64f53a3eaa0003f02ed174a7af958a3cdf33fda&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;https://github.com/mongodb/mongo/commit/b64f53a3eaa0003f02ed174a7af958a3cdf33fda&lt;/a&gt;&lt;/p&gt;</comment>
                            <comment id="123309" author="auto" created="Fri, 25 May 2012 23:45:04 +0000"  >&lt;p&gt;Author:&lt;/p&gt;
{u&apos;login&apos;: u&apos;astaple&apos;, u&apos;name&apos;: u&apos;Aaron&apos;, u&apos;email&apos;: u&apos;aaron@10gen.com&apos;}
&lt;p&gt;Message: &lt;a href=&quot;https://jira.mongodb.org/browse/SERVER-3918&quot; title=&quot;make sparse indexes error out on {$exists: false} queries&quot; class=&quot;issue-link&quot; data-issue-key=&quot;SERVER-3918&quot;&gt;&lt;del&gt;SERVER-3918&lt;/del&gt;&lt;/a&gt; Add MatcherVisitor for recursively accessing a Matcher&apos;s field matching properties.&lt;br/&gt;
Branch: master&lt;br/&gt;
&lt;a href=&quot;https://github.com/mongodb/mongo/commit/e5118d36ada90fad51606b5518326b3cbe48044f&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;https://github.com/mongodb/mongo/commit/e5118d36ada90fad51606b5518326b3cbe48044f&lt;/a&gt;&lt;/p&gt;</comment>
                            <comment id="123307" author="auto" created="Fri, 25 May 2012 23:45:01 +0000"  >&lt;p&gt;Author:&lt;/p&gt;
{u&apos;login&apos;: u&apos;astaple&apos;, u&apos;name&apos;: u&apos;Aaron&apos;, u&apos;email&apos;: u&apos;aaron@10gen.com&apos;}
&lt;p&gt;Message: &lt;a href=&quot;https://jira.mongodb.org/browse/SERVER-3918&quot; title=&quot;make sparse indexes error out on {$exists: false} queries&quot; class=&quot;issue-link&quot; data-issue-key=&quot;SERVER-3918&quot;&gt;&lt;del&gt;SERVER-3918&lt;/del&gt;&lt;/a&gt; Add IndexSpec::isSparse() accessor.&lt;br/&gt;
Branch: master&lt;br/&gt;
&lt;a href=&quot;https://github.com/mongodb/mongo/commit/57cbc35794c5d9a75a3b4a1523b653d8c39e9be8&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;https://github.com/mongodb/mongo/commit/57cbc35794c5d9a75a3b4a1523b653d8c39e9be8&lt;/a&gt;&lt;/p&gt;</comment>
                            <comment id="123152" author="auto" created="Fri, 25 May 2012 15:57:38 +0000"  >&lt;p&gt;Author:&lt;/p&gt;
{u&apos;login&apos;: u&apos;astaple&apos;, u&apos;name&apos;: u&apos;Aaron&apos;, u&apos;email&apos;: u&apos;aaron@10gen.com&apos;}
&lt;p&gt;Message: &lt;a href=&quot;https://jira.mongodb.org/browse/SERVER-3918&quot; title=&quot;make sparse indexes error out on {$exists: false} queries&quot; class=&quot;issue-link&quot; data-issue-key=&quot;SERVER-3918&quot;&gt;&lt;del&gt;SERVER-3918&lt;/del&gt;&lt;/a&gt; Refactor QueryPlanGenerator::addCachedPlan().&lt;br/&gt;
Branch: master&lt;br/&gt;
&lt;a href=&quot;https://github.com/mongodb/mongo/commit/ec8c7bc9b505d5d9f198ce83d3285bce05181dbf&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;https://github.com/mongodb/mongo/commit/ec8c7bc9b505d5d9f198ce83d3285bce05181dbf&lt;/a&gt;&lt;/p&gt;</comment>
                            <comment id="123151" author="auto" created="Fri, 25 May 2012 15:57:37 +0000"  >&lt;p&gt;Author:&lt;/p&gt;
{u&apos;login&apos;: u&apos;astaple&apos;, u&apos;name&apos;: u&apos;Aaron&apos;, u&apos;email&apos;: u&apos;aaron@10gen.com&apos;}
&lt;p&gt;Message: &lt;a href=&quot;https://jira.mongodb.org/browse/SERVER-3918&quot; title=&quot;make sparse indexes error out on {$exists: false} queries&quot; class=&quot;issue-link&quot; data-issue-key=&quot;SERVER-3918&quot;&gt;&lt;del&gt;SERVER-3918&lt;/del&gt;&lt;/a&gt; Refactor QueryPlanGenerator::addFallbackPlans() using the QueryPlan::Utility enum.&lt;br/&gt;
Branch: master&lt;br/&gt;
&lt;a href=&quot;https://github.com/mongodb/mongo/commit/9cfddde50b136106e35bf6ee9170a0f4a62483d5&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;https://github.com/mongodb/mongo/commit/9cfddde50b136106e35bf6ee9170a0f4a62483d5&lt;/a&gt;&lt;/p&gt;</comment>
                            <comment id="123150" author="auto" created="Fri, 25 May 2012 15:57:36 +0000"  >&lt;p&gt;Author:&lt;/p&gt;
{u&apos;login&apos;: u&apos;astaple&apos;, u&apos;name&apos;: u&apos;Aaron&apos;, u&apos;email&apos;: u&apos;aaron@10gen.com&apos;}
&lt;p&gt;Message: &lt;a href=&quot;https://jira.mongodb.org/browse/SERVER-3918&quot; title=&quot;make sparse indexes error out on {$exists: false} queries&quot; class=&quot;issue-link&quot; data-issue-key=&quot;SERVER-3918&quot;&gt;&lt;del&gt;SERVER-3918&lt;/del&gt;&lt;/a&gt; Make QueryPlan utility explicitly categorical using a QueryPlan::Utility enum.&lt;br/&gt;
Branch: master&lt;br/&gt;
&lt;a href=&quot;https://github.com/mongodb/mongo/commit/1aa4aa5efd184a07421fd3d4be996912cc2bfdd4&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;https://github.com/mongodb/mongo/commit/1aa4aa5efd184a07421fd3d4be996912cc2bfdd4&lt;/a&gt;&lt;/p&gt;</comment>
                            <comment id="123149" author="auto" created="Fri, 25 May 2012 15:57:34 +0000"  >&lt;p&gt;Author:&lt;/p&gt;
{u&apos;login&apos;: u&apos;astaple&apos;, u&apos;name&apos;: u&apos;Aaron&apos;, u&apos;email&apos;: u&apos;aaron@10gen.com&apos;}
&lt;p&gt;Message: &lt;a href=&quot;https://jira.mongodb.org/browse/SERVER-3918&quot; title=&quot;make sparse indexes error out on {$exists: false} queries&quot; class=&quot;issue-link&quot; data-issue-key=&quot;SERVER-3918&quot;&gt;&lt;del&gt;SERVER-3918&lt;/del&gt;&lt;/a&gt; Simplify QueryPlan interface description a bit.&lt;br/&gt;
Branch: master&lt;br/&gt;
&lt;a href=&quot;https://github.com/mongodb/mongo/commit/40d3419601ed15ae872717fc7d82d9a27f1cdd7e&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;https://github.com/mongodb/mongo/commit/40d3419601ed15ae872717fc7d82d9a27f1cdd7e&lt;/a&gt;&lt;/p&gt;</comment>
                            <comment id="123120" author="auto" created="Fri, 25 May 2012 15:11:11 +0000"  >&lt;p&gt;Author:&lt;/p&gt;
{u&apos;login&apos;: u&apos;astaple&apos;, u&apos;name&apos;: u&apos;Aaron&apos;, u&apos;email&apos;: u&apos;aaron@10gen.com&apos;}
&lt;p&gt;Message: &lt;a href=&quot;https://jira.mongodb.org/browse/SERVER-3918&quot; title=&quot;make sparse indexes error out on {$exists: false} queries&quot; class=&quot;issue-link&quot; data-issue-key=&quot;SERVER-3918&quot;&gt;&lt;del&gt;SERVER-3918&lt;/del&gt;&lt;/a&gt; Include pdfile.h in matcher_covered.cpp, fixing osx release build.&lt;br/&gt;
Branch: master&lt;br/&gt;
&lt;a href=&quot;https://github.com/mongodb/mongo/commit/1713c71f15b18ab166a54aa3d064180b209264a5&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;https://github.com/mongodb/mongo/commit/1713c71f15b18ab166a54aa3d064180b209264a5&lt;/a&gt;&lt;/p&gt;</comment>
                            <comment id="83865" author="thiloplanz" created="Wed, 1 Feb 2012 00:23:21 +0000"  >&lt;p&gt;&amp;gt;&quot; Sparse indexes by design change results (...) To put the other results after that would require doing a full table scan, which is not what people want nor expect.&quot;&lt;/p&gt;

&lt;p&gt;I strongly disagree with that. The presence or absence of an index should only change query performance, not the results.&lt;/p&gt;

&lt;p&gt;If a sparse index cannot be used properly for $exists, then it should not be used at all, even if that results in a full table scan. What should be documented for sparse indexes is that they cannot be used in these situations (not that they can be used but return different results, making the behaviour unpredictable if you cannot know what index will be used).&lt;/p&gt;

&lt;p&gt;For the cases where the current behaviour is acceptable or preferred, there should be a separate query operator (something like $exists_sparse) or it would need to be explicitly enabled by a query hint.&lt;/p&gt;</comment>
                            <comment id="83713" author="remonvv" created="Tue, 31 Jan 2012 16:40:32 +0000"  >&lt;p&gt;I think Tim&apos;s suggestion should definitely be looked at. It&apos;s true that for a lot of people the move to sparse indexes are motivated by the requirement that null values are not part of a unique constraint. Fully agree with Paul&apos;s comment.&lt;/p&gt;</comment>
                            <comment id="82713" author="saltlake" created="Fri, 27 Jan 2012 00:09:33 +0000"  >&lt;p&gt;This ticket should be updated to Major Priority.&lt;/p&gt;</comment>
                            <comment id="82442" author="saltlake" created="Thu, 26 Jan 2012 02:19:09 +0000"  >&lt;p&gt;I totally agree with Paul Canavese that sparse indexes should be used only on positive existence queries.&lt;/p&gt;

&lt;p&gt;When using a sparse index on a negative existence query the performance is excellent (it finishes in 0ms), but it will show a completely inaccurate result (0 matches).&lt;/p&gt;

&lt;p&gt;In fact I can&apos;t think of any situation where a negativ existence query would return a non-zero result when used with a sparse index. No sensible developer would expect a performance boost here, as the query couldn&apos;t be answered from the sparse index in any case.&lt;/p&gt;

&lt;p&gt;Using $natural:1 is also no good solution, as that would exclude any other indexes from being used.&lt;/p&gt;</comment>
                            <comment id="79684" author="canavese" created="Fri, 13 Jan 2012 17:20:23 +0000"  >&lt;p&gt;The other main use case is just to allow efficient lookups on a field that is sometimes null, without having an index bloated with entries for all the null cases.&lt;/p&gt;

&lt;p&gt;For example, consider a collection with 5 million documents and a &quot;keyword&quot; string field that is assigned 10% of the time.  The main use case is looking up documents based on a specific keyword.  So I don&apos;t want to eat up my memory with 4.5 million null keyword index entries.  &lt;/p&gt;

&lt;p&gt;But there may be secondary types of queries that then have unexpected behavior.  Say you have an admin page to show the most recent documents without keyword being set (= null).  If the keyword index gets used, you&apos;ll get nothing back.  If an index on a created_at field is used, you&apos;ll get matches back.  So with the current model you would need to understand that and hint to make sure you use the index that will return results.  For this query, there is no case in which it makes sense to use the keywords index, because it will always return nothing.&lt;/p&gt;

&lt;p&gt;In terms of selection/filtering, I suppose I could come up with use cases where the current model would be desirable, but they seem much more unusual to me.  If I wanted to query for a document with a keyword that is set but matching one or more specific values?&lt;/p&gt;

&lt;p&gt;So I think for selection I would want sparse indexes (by default at least) only to be used when &lt;b&gt;matching&lt;/b&gt; values (or for positive existence), but not for &lt;b&gt;excluding&lt;/b&gt; values (or for negative existence).  I believe that would always make the results consistent, whether an index is used or not.&lt;/p&gt;

&lt;p&gt;(Now, I hear Eliot when he&apos;s referring to the &lt;b&gt;sorting&lt;/b&gt; use case, which makes sense.  I&apos;m not entirely sure sure how to address that, although my inclination would still be to require hinting an index if using it would result in different behavior than without the index.)&lt;/p&gt;</comment>
                            <comment id="79672" author="tolsen" created="Fri, 13 Jan 2012 16:37:25 +0000"  >&lt;p&gt;I only require sparse indexes when I need a unique constraint on a field that can possibly be null (I want the unique constraint to not apply to the nulls).  Unfortunately, the sparse index leads to the weird behavior which is the subject of this bug report.  Do other users feel like they&apos;re being forced into using a sparse index (and the weird behavior that comes with) in this case?  Maybe the solution is to allow unique constraints on full indexes to ignore nulls.&lt;/p&gt;</comment>
                            <comment id="79624" author="eliot" created="Fri, 13 Jan 2012 13:59:47 +0000"  >&lt;p&gt;Sparse indexes by design change results, but we can make it a little easier to work with.&lt;/p&gt;

&lt;p&gt;For example, if you sort on a sparse field, then you only get results with that field.&lt;/p&gt;

&lt;p&gt;To put the other results after that would require doing a full table scan, which is not what people want nor expect.&lt;/p&gt;</comment>
                            <comment id="79609" author="hmexx007" created="Fri, 13 Jan 2012 11:43:54 +0000"  >&lt;p&gt;Perhaps the correct solution is to make the default behavior to NOT use any incomplete indices.  Since these are optimization tools, which require some level of database&amp;lt;-&amp;gt;app-layer cooperation (at least at the design stage), it&apos;s not unreasonable to ask the clients to include a &quot;allow incomplete index usage&quot; flag on a per-query basis.&lt;/p&gt;

&lt;p&gt;If you want to get real fancy, you could assign a &apos;consistency/completeness&apos; level to each non-complete index you create. You can then refer to which minimum level is acceptable on a per-query basis. &lt;/p&gt;

&lt;p&gt;db.test.ensureIndex(&lt;/p&gt;
{foo: 1}
&lt;p&gt;, &lt;/p&gt;
{sparse: true, safe: true, completeness: 3}
&lt;p&gt;db.test.find({foo: {$exists: false}}, &lt;/p&gt;
{completeness: 2}
&lt;p&gt;)  &lt;br/&gt;
db.test.find({foo: {$exists: false}}, &lt;/p&gt;
{completeness: 4}
&lt;p&gt;)   &amp;lt;--- would not use sparse index&lt;/p&gt;

&lt;p&gt;This would work really well for multi-level archiving using filtered indexes. Last hour&apos;s data could be on a level 1 index, last day level 2 and so forth... all accessible with just the change of a number on the client side.&lt;/p&gt;</comment>
                            <comment id="79405" author="canavese" created="Thu, 12 Jan 2012 19:06:47 +0000"  >&lt;p&gt;I agree this is very confusing, and it causes even more confusing side effects with the query optimizer (see &lt;a href=&quot;https://jira.mongodb.org/browse/SERVER-4665&quot; class=&quot;external-link&quot; rel=&quot;nofollow&quot;&gt;https://jira.mongodb.org/browse/SERVER-4665&lt;/a&gt;).  We had the unfortunate experience of having old working queries in our app break when we later added an index.  I vote for indexes only affecting query performance, not behavior.&lt;/p&gt;</comment>
                            <comment id="79402" author="fbjork" created="Thu, 12 Jan 2012 19:02:09 +0000"  >&lt;p&gt;Agree, this is not expected behavior.&lt;/p&gt;</comment>
                            <comment id="75542" author="nsanch" created="Thu, 22 Dec 2011 19:54:51 +0000"  >&lt;p&gt;I agree with Remon here &amp;#8211; the presence of an index should not change the behavior of a query, only its performance.&lt;/p&gt;

&lt;p&gt;Can &lt;a href=&quot;http://www.mongodb.org/display/DOCS/Advanced+Queries#AdvancedQueries-%24exists&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;http://www.mongodb.org/display/DOCS/Advanced+Queries#AdvancedQueries-%24exists&lt;/a&gt; and &lt;a href=&quot;http://www.mongodb.org/display/DOCS/Indexes#Indexes-SparseIndexes&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;http://www.mongodb.org/display/DOCS/Indexes#Indexes-SparseIndexes&lt;/a&gt; be updated to reflect this design?&lt;/p&gt;</comment>
                            <comment id="69358" author="drewtron" created="Mon, 28 Nov 2011 20:11:25 +0000"  >&lt;p&gt;I ran into this same issue.  While it may be documented, it still caused some confusion for me.  It does seem odd that queries return different results based the presence of an index.  I would prefer a slow query with correct results over a fast query with incorrect results, regardless of my poor index creation.  My solution was to simply change the index to a dense index.&lt;/p&gt;</comment>
                            <comment id="67764" author="eliot" created="Sun, 20 Nov 2011 06:37:25 +0000"  >&lt;p&gt;Its documented at the sparse index docs.&lt;/p&gt;

&lt;p&gt;Sparse indexes are meant to have different results in certain cases, so not sure where this case falls.&lt;/p&gt;</comment>
                            <comment id="67763" author="eliot" created="Sun, 20 Nov 2011 06:37:24 +0000"  >&lt;p&gt;Its documented at the sparse index docs.&lt;/p&gt;

&lt;p&gt;Sparse indexes are meant to have different results in certain cases, so not sure where this case falls.&lt;/p&gt;</comment>
                            <comment id="67553" author="remonvv" created="Fri, 18 Nov 2011 08:39:41 +0000"  >&lt;p&gt;I think it would be really good to prioritize query behaviour consistency here and guarantee that indexes will only ever affect performance. I&apos;m aware this might introduce some implementation difficulty and/or reduced performance but that&apos;s almost always a smaller issue than &quot;unpredictable&quot; results.&lt;/p&gt;

&lt;p&gt;For now, I would suggest adding a note to the documentation at both the sparse index documentation as well as $exists. I&apos;d do it but I do not seem to have access.&lt;/p&gt;</comment>
                            <comment id="56143" author="eliot" created="Fri, 23 Sep 2011 12:39:49 +0000"  >&lt;p&gt;sparse indexes are the only index type which changes results.&lt;br/&gt;
The question for this cases is whether $exists should be special cased to work in all cases.&lt;br/&gt;
It probably should - but its not 100% clear. &lt;/p&gt;</comment>
                            <comment id="56120" author="remonvv" created="Fri, 23 Sep 2011 09:07:39 +0000"  >&lt;p&gt;How can this possibly be expected behaviour? Query semantics should be so that col.count() = col.count({f:{$exists:false}}) + col.count({f:{$exists:true}}). This surely can&apos;t even be up for debate regardless of the index type. If the query plan cannot use an index to produce the correct results, don&apos;t use the index. It&apos;s up to the user to make queries that hit indexes but it is not up to the user to have to guesstimate which query produces correct results, especially if this requires more than intermediate knowledge of how the indexes are implemented and which indexes the query optimizer will use for specific queries.&lt;/p&gt;</comment>
                            <comment id="55858" author="scotthernandez" created="Thu, 22 Sep 2011 11:54:08 +0000"  >&lt;p&gt;Yes, when $exists didn&apos;t use an index that particular query pattern didn&apos;t produce these results, but as you mention, null comparisons still did.&lt;/p&gt;

&lt;p&gt;This will be even more complicated once filtered indexes are implemented. At that point I&apos;m not sure there can be useful logic for how to make this decision and when special indexes should be used/avoided.&lt;/p&gt;

&lt;p&gt;It seems like the responsibility must be left to the user to craft queries in ways which make logical sense with the indexes they have defined. SERVER-785&lt;/p&gt;</comment>
                            <comment id="55843" author="ben.spencer@digitalwindow.com" created="Thu, 22 Sep 2011 10:03:17 +0000"  >&lt;p&gt;Note that this a regression from 1.8 (because 1.8 didn&apos;t use indexes on $exists queries at all?).&lt;/p&gt;

&lt;p&gt;Surely the query plan that happens to be chosen shouldn&apos;t affect the semantics of the query?  In the above example it will always use the sparse index, but in a more complex situation the index chosen could depend on the data in the collection.&lt;/p&gt;

&lt;p&gt;A similar effect occurs when querying for &lt;/p&gt;
{foo: null}
&lt;p&gt;.  If the sparse index is used, it will only return docs with foo explicitly set to null; if not, it will also return docs without foo set (this behaviour is the same in 1.8 however).&lt;/p&gt;</comment>
                            <comment id="55802" author="eliot" created="Thu, 22 Sep 2011 03:26:03 +0000"  >&lt;p&gt;That is expected.&lt;br/&gt;
I guess it would be better to error out&lt;/p&gt;</comment>
                    </comments>
                <issuelinks>
                            <issuelinktype id="10011">
                    <name>Depends</name>
                                                                <inwardlinks description="is depended on by">
                                                        </inwardlinks>
                                    </issuelinktype>
                            <issuelinktype id="10010">
                    <name>Duplicate</name>
                                                                <inwardlinks description="is duplicated by">
                                        <issuelink>
            <issuekey id="27402">SERVER-4578</issuekey>
        </issuelink>
            <issuelink>
            <issuekey id="28202">SERVER-4666</issuekey>
        </issuelink>
                            </inwardlinks>
                                    </issuelinktype>
                            <issuelinktype id="10012">
                    <name>Related</name>
                                            <outwardlinks description="related to">
                                                        </outwardlinks>
                                                        </issuelinktype>
                    </issuelinks>
                <attachments>
                    </attachments>
                <subtasks>
                    </subtasks>
                <customfields>
                                                <customfield id="customfield_10050" key="com.atlassian.jira.toolkit:comments">
                        <customfieldname># Replies</customfieldname>
                        <customfieldvalues>
                            <customfieldvalue>29.0</customfieldvalue>
                        </customfieldvalues>
                    </customfield>
                                                                                                                                                                                                                                                                                                                                                                                                                                                                        <customfield id="customfield_10011" key="com.atlassian.jira.plugin.system.customfieldtypes:radiobuttons">
                        <customfieldname>Backwards Compatibility</customfieldname>
                        <customfieldvalues>
                                <customfieldvalue key="10012"><![CDATA[Major Change]]></customfieldvalue>

                        </customfieldvalues>
                    </customfield>
                                                                                                                                                                                                                                                                                                                                                                                                                                            <customfield id="customfield_10055" key="com.atlassian.jira.ext.charting:firstresponsedate">
                        <customfieldname>Date of 1st Reply</customfieldname>
                        <customfieldvalues>
                            <customfieldvalue>Thu, 22 Sep 2011 03:26:03 +0000</customfieldvalue>

                        </customfieldvalues>
                    </customfield>
                                                                <customfield id="customfield_10052" key="com.atlassian.jira.toolkit:dayslastcommented">
                        <customfieldname>Days since reply</customfieldname>
                        <customfieldvalues>
                                        11 years, 33 weeks, 6 days ago
    
                        </customfieldvalues>
                    </customfield>
                                                                <customfield id="customfield_18254" key="com.onresolve.jira.groovy.groovyrunner:scripted-field">
                        <customfieldname>Dependencies</customfieldname>
                        <customfieldvalues>
                            <customfieldvalue><![CDATA[]]></customfieldvalue>


                        </customfieldvalues>
                    </customfield>
                                                                <customfield id="customfield_15850" key="com.atlassian.jira.plugins.jira-development-integration-plugin:devsummary">
                        <customfieldname>Development</customfieldname>
                        <customfieldvalues>
                            
                        </customfieldvalues>
                    </customfield>
                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                    <customfield id="customfield_10057" key="com.atlassian.jira.toolkit:lastusercommented">
                        <customfieldname>Last comment by Customer</customfieldname>
                        <customfieldvalues>
                            <customfieldvalue>true</customfieldvalue>
                        </customfieldvalues>
                    </customfield>
                                                                                            <customfield id="customfield_10056" key="com.atlassian.jira.toolkit:lastupdaterorcommenter">
                        <customfieldname>Last commenter</customfieldname>
                        <customfieldvalues>
                            <customfieldvalue>dan@mongodb.com</customfieldvalue>

                        </customfieldvalues>
                    </customfield>
                                                                <customfield id="customfield_11151" key="com.atlassian.jira.toolkit:LastCommentDate">
                        <customfieldname>Last public comment date</customfieldname>
                        <customfieldvalues>
                            11 years, 33 weeks, 6 days ago
                        </customfieldvalues>
                    </customfield>
                                                                                                                        <customfield id="customfield_10000" key="com.atlassian.jira.plugin.system.customfieldtypes:radiobuttons">
                        <customfieldname>Old_Backport</customfieldname>
                        <customfieldvalues>
                                <customfieldvalue key="10000"><![CDATA[No]]></customfieldvalue>

                        </customfieldvalues>
                    </customfield>
                                                                <customfield id="customfield_10032" key="com.atlassian.jira.plugin.system.customfieldtypes:select">
                        <customfieldname>Operating System</customfieldname>
                        <customfieldvalues>
                                <customfieldvalue key="10026"><![CDATA[ALL]]></customfieldvalue>

                        </customfieldvalues>
                    </customfield>
                                                                                                                                                                                <customfield id="customfield_10051" key="com.atlassian.jira.toolkit:participants">
                        <customfieldname>Participants</customfieldname>
                        <customfieldvalues>
                                        <customfieldvalue>aaron</customfieldvalue>
            <customfieldvalue>drewtron</customfieldvalue>
            <customfieldvalue>auto</customfieldvalue>
            <customfieldvalue>ben.spencer@digitalwindow.com</customfieldvalue>
            <customfieldvalue>eliot</customfieldvalue>
            <customfieldvalue>fbjork</customfieldvalue>
            <customfieldvalue>hmexx007</customfieldvalue>
            <customfieldvalue>saltlake</customfieldvalue>
            <customfieldvalue>nsanch</customfieldvalue>
            <customfieldvalue>canavese</customfieldvalue>
            <customfieldvalue>remonvv</customfieldvalue>
            <customfieldvalue>scotthernandez</customfieldvalue>
            <customfieldvalue>thiloplanz</customfieldvalue>
            <customfieldvalue>tolsen</customfieldvalue>
    
                        </customfieldvalues>
                    </customfield>
                                                                                                                                                                                                                                        <customfield id="customfield_14254" key="com.pyxis.greenhopper.jira:gh-lexo-rank">
                        <customfieldname>Product Rank</customfieldname>
                        <customfieldvalues>
                            <customfieldvalue>1|hropyf:</customfieldvalue>

                        </customfieldvalues>
                    </customfield>
                                                                                                                                                                                <customfield id="customfield_12550" key="com.pyxis.greenhopper.jira:gh-lexo-rank">
                        <customfieldname>Rank</customfieldname>
                        <customfieldvalues>
                            <customfieldvalue>2|hrgcyn:</customfieldvalue>

                        </customfieldvalues>
                    </customfield>
                                                                <customfield id="customfield_10558" key="com.pyxis.greenhopper.jira:gh-global-rank">
                        <customfieldname>Rank (Obsolete)</customfieldname>
                        <customfieldvalues>
                            <customfieldvalue>9009</customfieldvalue>
                        </customfieldvalues>
                    </customfield>
                                                                                            <customfield id="customfield_23361" key="com.onresolve.jira.groovy.groovyrunner:scripted-field">
                        <customfieldname>Requested By</customfieldname>
                        <customfieldvalues>
                                

                        </customfieldvalues>
                    </customfield>
                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                <customfield id="customfield_10166" key="com.atlassian.jira.plugin.system.customfieldtypes:radiobuttons">
                        <customfieldname>Tests Written</customfieldname>
                        <customfieldvalues>
                                <customfieldvalue key="10154"><![CDATA[Complete]]></customfieldvalue>

                        </customfieldvalues>
                    </customfield>
                                                                <customfield id="customfield_10053" key="com.atlassian.jira.ext.charting:timeinstatus">
                        <customfieldname>Time In Status</customfieldname>
                        <customfieldvalues>
                            
                        </customfieldvalues>
                    </customfield>
                                                                                                                                                                                                                                                                                                                                                                                                                                                                        <customfield id="customfield_22870" key="com.onresolve.jira.groovy.groovyrunner:scripted-field">
                        <customfieldname>Triagers</customfieldname>
                        <customfieldvalues>
                                

                        </customfieldvalues>
                    </customfield>
                                                                                                                                                                                                                                                                                                                                                                                    <customfield id="customfield_14350" key="com.pyxis.greenhopper.jira:gh-lexo-rank">
                        <customfieldname>serverRank</customfieldname>
                        <customfieldvalues>
                            <customfieldvalue>1|hrokcv:</customfieldvalue>

                        </customfieldvalues>
                    </customfield>
                                    </customfields>
    </item>
</channel>
</rss>