[BUG] Type inference error on cypher queries.

[zhanglei1949]

I have define a graph with two types of vertices, each is uniquely identified by primary key custom_id which is of type DT_SIGNED_INT64.

name: modern_graph # then must have a modern dir under ${data} directory
version: v0.1
store_type: mutable_csr  # v6d, groot, gart
description: A graph with 2 vertex types and 2 edge types
schema:
  vertex_types:
    - type_id: 0
      type_name: person
      description: A person vertex type
      properties:
        - property_id: 0
          property_name: custom_id
          property_type:
            primitive_type: DT_SIGNED_INT64
        - property_id: 1
          property_name: name
          property_type:
            string:
              long_text:
        - property_id: 2
          property_name: age
          property_type:
            primitive_type: DT_SIGNED_INT32
      primary_keys:
        - id
    - type_id: 1
      type_name: software
      description: A software vertex type
      properties:
        - property_id: 0
          property_name: custom_id
          property_type:
            primitive_type: DT_SIGNED_INT64
        - property_id: 1
          property_name: name
          property_type:
            string:
              long_text:
        - property_id: 2
          property_name: lang
          property_type:
            string:
              long_text:
      primary_keys:
        - id
  edge_types:
    - type_id: 0
      type_name: knows
      description: A knows edge type
      vertex_type_pair_relations:
        - source_vertex: person
          destination_vertex: person
          relation: MANY_TO_MANY
          x_csr_params:
            sort_on_compaction: TRUE
      properties:
        - property_id: 0
          property_name: weight
          property_type:
            primitive_type: DT_DOUBLE
    - type_id: 1
      type_name: created
      description: A created edge type
      vertex_type_pair_relations:
        - source_vertex: person
          destination_vertex: software
          relation: MANY_TO_MANY
      properties:
        - property_id: 0
          property_name: weight
          property_type:
            primitive_type: DT_DOUBLE

But following two queries give different physical plan

MATCH(n :person {custom_id: 1L}) return n;
MATCH(n  {custom_id: 1L}) return n;

For each first query the plan is like

 opr {
    scan {
      alias {
      }
      params {
        tables {
          id: 0
        }
        sample_ratio: 1
      }
      idx_predicate {
        or_predicates {
          predicates {
            key {
              key {
                name: "custom_id"
              }
            }
            const {
              i64: 1
            }
          }
        }
      }
    }
  }
  meta_data {
    type {
      graph_type {
        graph_data_type {
          label {
          }
          props {
            prop_id {
              name: "custom_id"
            }
            type: INT64
          }
          props {
            prop_id {
              name: "name"
            }
            type: STRING
          }
          props {
            prop_id {
              name: "age"
            }
            type: INT32
          }
        }
      }
    }
  }

For the second one, the plan is like

plan {
  opr {
    scan {
      alias {
      }
      params {
        tables {
          id: 0
        }
        tables {
          id: 1
        }
        sample_ratio: 1
      }
      idx_predicate {
        or_predicates {
          predicates {
            key {
              key {
                name: "custom_id"
              }
            }
            const {
              i32: 1
            }
          }
        }
      }
    }
  }

Which different data type is given, i.e. i32 vs i64

[shirly121]

Ensure the following configuration is correct:

1. graph.planner.opt: RBO
2. graph.physical.opt: proto

Based on the above configuration, the type of 1L is inferred as i64, which meets expectations.

[github-actions]

/cc @shirly121, this issus/pr has had no activity for for a long time, could you folks help to review the status ?
To suppress further notifications,

• for issues,
  • if it is waiting for further response from the reporter/author, please help to add the label requires-further-info,
  • if you have already started working on it, please add the label work-in-progress to the issue,
  • if this issue requires further designing discussion and not in current plan, or won't be fixed, please add the label requires-further-discussion or wontfix to the issue,
• for pull requests,
  • if you are still working on it and it is not ready for reviewing, please convert this pull request as draft PR,
  • if you have decided to hold this development on, please add the requires-further-discussion label to the pull request.
    Thanks!