Uploaded image for project: 'Calcite'
  1. Calcite
  2. CALCITE-740

Redundant WHERE clause causes wrong result in MongoDB adapter

        Details

        • Type: Bug
        • Status: Closed
        • Priority: Major
        • Resolution: Fixed
        • Affects Version/s: 1.2.0-incubating
        • Fix Version/s: 1.4.0-incubating
        • Component/s: None
        • Labels:
          None

          Description

          Running a query with the 'where' clause:
          where (pop > 8000 and pop > 9000)
          does not produce the same result as:
          where pop > 9000
          instead it produces the same result as:
          where pop > 8000

          This was run using calcite-mongo's zips collection.

          The interpreter appears to treat the 'and' as an 'or'. This despite the fact that queries like:
          where (pop > 8000 and pop < 9000)
          work as you would expect.

          Tried this on other data stores and did not see the same problem. Just calcite-mongo.

            Activity

            Ascending order - Click to sort in descending order
            Hide
            Permalink
            julianhyde Julian Hyde added a comment -

            I tried

              @Test public void testFilterPair() {
    final int expected9k = 8125;
    final int expected8k = 8707;
    asd(expected9k, "where pop > 8000 and pop > 9000");
    asd(expected9k, "where pop > 9000");
    asd(expected8k, "where pop > 8000");
    asd(expected9k, "where pop > 9000 and pop > 8000");
    asd(expected8k, "where pop > 9000 or pop > 8000");
    asd(expected8k, "where pop > 8000 or pop > 9000");
  }

  private void asd(int expected, String q) {
    CalciteAssert.that()
        .enable(enabled())
        .with(ZIPS)
        .query("select count(*) as c from zips\n" + q)
        .returns("C=" + expected + "\n");
    CalciteAssert.that()
        .enable(enabled())
        .with(ZIPS)
        .query("select * from zips\n" + q)
        .returnsCount(expected);
  }

            and it gave desired results.

            Show
            julianhyde Julian Hyde added a comment - I tried @Test public void testFilterPair() { final int expected9k = 8125; final int expected8k = 8707; asd(expected9k, "where pop > 8000 and pop > 9000" ); asd(expected9k, "where pop > 9000" ); asd(expected8k, "where pop > 8000" ); asd(expected9k, "where pop > 9000 and pop > 8000" ); asd(expected8k, "where pop > 9000 or pop > 8000" ); asd(expected8k, "where pop > 8000 or pop > 9000" ); } private void asd( int expected, String q) { CalciteAssert.that() .enable(enabled()) .with(ZIPS) .query( "select count(*) as c from zips\n" + q) .returns( "C=" + expected + "\n" ); CalciteAssert.that() .enable(enabled()) .with(ZIPS) .query( "select * from zips\n" + q) .returnsCount(expected); } and it gave desired results.
            Hide
            Permalink
            julianhyde Julian Hyde added a comment -

            Ah, I've reproduced it now, with "pop < 8000 and pop < 9000". I'm running JDK 1.8 and I guess you're running 1.7 and have different hash-table orders.

            Show
            julianhyde Julian Hyde added a comment - Ah, I've reproduced it now, with "pop < 8000 and pop < 9000". I'm running JDK 1.8 and I guess you're running 1.7 and have different hash-table orders.
            Hide
            Permalink
            julianhyde Julian Hyde added a comment -

            Fixed in http://git-wip-us.apache.org/repos/asf/incubator-calcite/commit/6ece12a8.

            Show
            julianhyde Julian Hyde added a comment - Fixed in http://git-wip-us.apache.org/repos/asf/incubator-calcite/commit/6ece12a8 .
            Hide
            Permalink
            jnadeau Jacques Nadeau added a comment -

            Resolved in release 1.4.0-incubating (2015-08-23)

            Show
            jnadeau Jacques Nadeau added a comment - Resolved in release 1.4.0-incubating (2015-08-23)

              People

              • Assignee:
                julianhyde Julian Hyde
                Reporter:
                rantonucci Robert Antonucci
              • Votes:
                0 Vote for this issue
                Watchers:
                3 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved:

                  Development