Uploaded image for project: 'Calcite'
  1. Calcite
  2. CALCITE-530 Phoenix support
  3. CALCITE-992

Validate and resolve sequence reference as a Table object

    Details

    • Type: Sub-task
    • Status: Closed
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 1.6.0
    • Component/s: None
    • Labels:
      None

      Description

      Currently the validator does not validate if the sequence exists or if the corresponding table is of the required type, etc. Also, in NEXT_VALUE and CURRENT_VALUE function, we need the sequence Table object instead of the sequence name string.

        Activity

        Hide
        julianhyde Julian Hyde added a comment -

        Resolved in release 1.6.0 (2016-01-22).

        Show
        julianhyde Julian Hyde added a comment - Resolved in release 1.6.0 (2016-01-22).
        Hide
        maryannxue Maryann Xue added a comment -
        Show
        maryannxue Maryann Xue added a comment - Fixed in http://git-wip-us.apache.org/repos/asf/calcite/commit/de38802 . Thanks , Julian Hyde , for your help!
        Hide
        maryannxue Maryann Xue added a comment -

        Thank you, Julian Hyde, for making the changes! Yes, the THREAD_LOCAL object does exactly what is needed, with the help of the "to string" and "from string" for qualified names. I have some minor questions, which I have posted on the pull request.

        Show
        maryannxue Maryann Xue added a comment - Thank you, Julian Hyde , for making the changes! Yes, the THREAD_LOCAL object does exactly what is needed, with the help of the "to string" and "from string" for qualified names. I have some minor questions, which I have posted on the pull request.
        Hide
        julianhyde Julian Hyde added a comment -

        Maryann Xue, I created a branch https://github.com/julianhyde/calcite/tree/992-validate-seq with your change, then I made my own change, backing out some of your edits and adding my own. You'll see that I don't pass the sequence table object but instead pass its unique name (a list of strings, converted temporarily into a single string like "schema"."table". That string can be converted to a string list, then used to get a RelOptTable inside the code that implements the sequence function by generating java code. Hopefully that's what you need.

        Show
        julianhyde Julian Hyde added a comment - Maryann Xue , I created a branch https://github.com/julianhyde/calcite/tree/992-validate-seq with your change, then I made my own change, backing out some of your edits and adding my own. You'll see that I don't pass the sequence table object but instead pass its unique name (a list of strings, converted temporarily into a single string like "schema"."table" . That string can be converted to a string list, then used to get a RelOptTable inside the code that implements the sequence function by generating java code. Hopefully that's what you need.
        Hide
        julianhyde Julian Hyde added a comment -

        Maryann Xue, The functionality I mentioned in our call this morning was EnumerableRelImplementor.stash. It allows you to pass in an object at implement time (i.e. when you are converting a RelNode tree to java code) and to be able to get that object at execute time (i.e. after that java code has been compiled using janino and is being run). See CALCITE-506.

        I don't know whether it solves the problem we have here, but I thought I'd mention it. The life cycle is slightly different. It's as if we need to stash an object (the sequence object) at parse/validate time and retrieve that object at implement or run time. But without putting the object into the RexNode tree. What we'd put into the RexNode tree is a RexDynamicParam with a unique name, and we'd have a map somewhere outside the RexNode tree from that name to the object value.

        Show
        julianhyde Julian Hyde added a comment - Maryann Xue , The functionality I mentioned in our call this morning was EnumerableRelImplementor.stash. It allows you to pass in an object at implement time (i.e. when you are converting a RelNode tree to java code) and to be able to get that object at execute time (i.e. after that java code has been compiled using janino and is being run). See CALCITE-506 . I don't know whether it solves the problem we have here, but I thought I'd mention it. The life cycle is slightly different. It's as if we need to stash an object (the sequence object) at parse/validate time and retrieve that object at implement or run time. But without putting the object into the RexNode tree. What we'd put into the RexNode tree is a RexDynamicParam with a unique name, and we'd have a map somewhere outside the RexNode tree from that name to the object value.
        Hide
        maryannxue Maryann Xue added a comment -

        BTW, the existing test cases in sequence.oq pass with this patch, and I'll add counter cases later. Having a new RexNode type would require same amount of changes but would look nicer, IMO.

        Show
        maryannxue Maryann Xue added a comment - BTW, the existing test cases in sequence.oq pass with this patch, and I'll add counter cases later. Having a new RexNode type would require same amount of changes but would look nicer, IMO.
        Hide
        maryannxue Maryann Xue added a comment -

        I managed to put together the validation and sequence resolving stuff, but had a little problem with making the RelOptTable a RexLiteral. The current patch looks a bit ugly since the changes get everywhere in order to make RexLiteral enclose this RelOptTable object. An alternative I'm thinking is to create a new RexNode type, say, RexTableReference (or RexSequenceReference). Any suggestions, Julian Hyde?

        Show
        maryannxue Maryann Xue added a comment - I managed to put together the validation and sequence resolving stuff, but had a little problem with making the RelOptTable a RexLiteral. The current patch looks a bit ugly since the changes get everywhere in order to make RexLiteral enclose this RelOptTable object. An alternative I'm thinking is to create a new RexNode type, say, RexTableReference (or RexSequenceReference). Any suggestions, Julian Hyde ?

          People

          • Assignee:
            maryannxue Maryann Xue
            Reporter:
            maryannxue Maryann Xue
          • Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development