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

JavaRowFormat.comparer relies on proper equals/compareTo in custom row classes

    XMLWordPrintableJSON

    Details

    • Type: Bug
    • Status: Open
    • Priority: Minor
    • Resolution: Unresolved
    • Affects Version/s: 0.9.1-incubating
    • Fix Version/s: None
    • Component/s: None
    • Labels:

      Description

      When reviewing CALCITE-397 I noted that the fix was "convert to the target row type, then perform distinct".

      I wondered: why don't we perform distinct first, then convert row types? That might be much more efficient if the distinct reduces the number of rows dramatically, so we do not spend time on conversion.

      When I did tried this change, I noticed Calcite uses "default equals/compareTo".

      Not sure what is the best approach here: raise errors in such cases, create synthetic equals/hashCode/compareTo somehow, or reconvert to the type with proper comparison methods.

      Here's the change to use "distinct, then convert to the target physType":

                  Expressions.return_(
                      null,
      +                inputPhysType.convertTo(
                      Expressions.call(
      +                    childExp,
      -                    inputPhysType.convertTo(childExp, physType),
                          BuiltinMethod.DISTINCT.method,
                          Expressions.<Expression>list()
                                  .appendIfNotNull(inputPhysType.comparer()))
      +                          , physType)
                          ));
      

      The generated java code is as following (note how .distinct() is used over JdbcTest$Employee that has no equals/compareTo methods):

      /*   3 */ public net.hydromatic.linq4j.Enumerable bind(final net.hydromatic.optiq.DataContext root0) {
      /*   4 */   root = root0;
      /*   5 */   return net.hydromatic.linq4j.Linq4j.asEnumerable(((net.hydromatic.optiq.test.JdbcTest.HrSchema) ((net.hydromatic.optiq.impl.java.ReflectiveSchema) root.getRootSchema().getSubSchema("hr").unwrap(net.hydromatic.optiq.impl.java.ReflectiveSchema.class)).getTarget()).emps).distinct().select(new net.hydromatic.linq4j.function.Function1() {
      /*   6 */       public Object[] apply(net.hydromatic.optiq.test.JdbcTest.Employee o) {
      /*   7 */         return new Object[] {
      /*   8 */             o.empid,
      /*   9 */             o.deptno,
      /*  10 */             o.name,
      /*  11 */             o.salary,
      /*  12 */             o.commission};
      /*  13 */       }
      /*  14 */       public Object apply(Object o) {
      /*  15 */         return apply(
      /*  16 */           (net.hydromatic.optiq.test.JdbcTest.Employee) o);
      /*  17 */       }
      /*  18 */     }
      /*  19 */     );
      /*  20 */ }
      

        Attachments

          Activity

            People

            • Assignee:
              vladimirsitnikov Vladimir Sitnikov
              Reporter:
              vladimirsitnikov Vladimir Sitnikov
            • Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

              • Created:
                Updated: