Project

General

Profile

Bug #11974

Unknown frame element: TABLE when a shared frame is formed from a table name

Added by Octavian Adrian Gavril 22 days ago. Updated 20 days ago.

Status:
Test
Priority:
Normal
Assignee:
Octavian Adrian Gavril
Target version:
-
Start date:
Due date:
% Done:

100%

billable:
No
vendor_id:
GCD
case_num:
version_reported:
version_resolved:
16802
reviewer:
Constantin Asofiei
production:
No
env_name:
topics:
Conversion

History

#1 Updated by Octavian Adrian Gavril 22 days ago

  • topics Conversion added

The conversion fails when a table name is used as a frame element inside a FORM block.

Here is a test case:

start.p:

define new shared frame f1.

form
    frmtab
with frame f1 width 80.

Associated .df file:

ADD TABLE "frmtab" 
  AREA "Schema Area" 
  DUMP-NAME "frmtab" 

ADD FIELD "code" OF "frmtab" AS character
  FORMAT "x(8)" 
  INITIAL "" 
  LABEL "Code" 
  POSITION 2
  MAX-WIDTH 16
  ORDER 10

ADD FIELD "descr" OF "frmtab" AS character  
ADD FIELD "qty"   OF "frmtab" AS integer    

ADD INDEX "codeidx" ON "frmtab" 
  AREA "Schema Area" 
  UNIQUE
  PRIMARY
  INDEX-FIELD "code" ASCENDING

.
PSC
cpstream=1252
.
0000005407

In OE, this statement generates a form containing all fields of the table. However, during conversion, the following error is thrown:

#2 Updated by Octavian Adrian Gavril 22 days ago

  • Status changed from New to WIP
  • Assignee set to Octavian Adrian Gavril

The root cause of this issue is that FrameAstKey.equals() silently skips the TABLE node, whereas computeHash() throws an exception.

I'm currently preparing a fix for this.

#3 Updated by Octavian Adrian Gavril 22 days ago

  • Status changed from WIP to Review
  • % Done changed from 0 to 100
  • reviewer Constantin Asofiei added

Created task branch 11974a.

I've committed the fix in 11974a/16796. I added support for the TABLE node inside the equals(), computeHash(), and getNextSignificantNode() methods.

I noticed that Constantin worked in this area as well, so Constantin, please review the changes.

#4 Updated by Constantin Asofiei 22 days ago

  • Status changed from Review to Internal Test

Octavian Adrian Gavril wrote:

Created task branch 11974a.

I've committed the fix in 11974a/16796. I added support for the TABLE node inside the equals(), computeHash(), and getNextSignificantNode() methods.

I noticed that Constantin worked in this area as well, so Constantin, please review the changes.

The changes makes sense. Please post how the AST looks like for the test in first note.

#5 Updated by Octavian Adrian Gavril 22 days ago

Constantin Asofiei wrote:

The changes makes sense. Please post how the AST looks like for the test in first note.

Here is how the associated AST looked at the moment of failure:

    <ast col="0" id="12884901902" line="0" text="statement" type="STATEMENT">
      <ast col="1" id="12884901903" line="3" text="form" type="KW_FORM">
        <annotation datatype="java.lang.String" key="support_level-byrule" value="gaps/gap_analysis_marking.xml:436"/>
        <annotation datatype="java.lang.Long" key="support_level" value="16400"/>
        <ast col="5" id="12884901905" line="4" text="frmtab" type="TABLE">
          <annotation datatype="java.lang.String" key="db_signature" value="char|char|int%UP^codeidx^0|char"/>
          <annotation datatype="java.lang.String" key="schemaname" value="fwd.frmtab"/>
          <annotation datatype="java.lang.Long" key="recordtype" value="12"/>
          <annotation datatype="java.lang.String" key="dbname" value="fwd"/>
          <annotation datatype="java.lang.String" key="bufname" value="fwd.frmtab"/>
        </ast>
        <ast col="1" id="12884901907" line="5" text="with" type="FRAME_PHRASE">
          <ast col="6" id="12884901909" line="5" text="frame" type="KW_FRAME">
            <annotation datatype="java.lang.String" key="support_level-byrule" value="gaps/gap_analysis_marking.xml:436"/>
            <annotation datatype="java.lang.Long" key="support_level" value="16400"/>
            <ast col="12" id="12884901911" line="5" text="f1" type="WID_FRAME"/>
          </ast>
          <ast col="15" id="12884901913" line="5" text="width" type="KW_WIDTH">
            <annotation datatype="java.lang.String" key="support_level-byrule" value="gaps/gap_analysis_marking.xml:436"/>
            <annotation datatype="java.lang.Long" key="support_level" value="16400"/>
            <ast col="21" id="12884901915" line="5" text="80" type="NUM_LITERAL">
              <annotation datatype="java.lang.String" key="support_level-byrule" value="gaps/gap_analysis_marking.xml:436"/>
              <annotation datatype="java.lang.Long" key="support_level" value="16400"/>
            </ast>
          </ast>
        </ast>
      </ast>
    </ast>

#6 Updated by Constantin Asofiei 22 days ago

Thanks, looks good.

#7 Updated by Octavian Adrian Gavril 22 days ago

Should I start conversion regression testing for a few apps?

#8 Updated by Constantin Asofiei 22 days ago

Octavian Adrian Gavril wrote:

Should I start conversion regression testing for a few apps?

Yes, please.

#10 Updated by Octavian Adrian Gavril 21 days ago

I tested full conversions for Hotel ChUI, Hotel GUI, ChUI regression testing app, OO app, and ETF. There are no generated output differences for any of these projects. The testcase and the module from #10566 are fixed as well.

I haven't tested any large GUI customer apps yet. Is that necessary, or is the current testing sufficient?

#11 Updated by Constantin Asofiei 21 days ago

Octavian Adrian Gavril wrote:

I haven't tested any large GUI customer apps yet. Is that necessary, or is the current testing sufficient?

Please run that also.

#12 Updated by Octavian Adrian Gavril 21 days ago

Constantin Asofiei wrote:

Octavian Adrian Gavril wrote:

I haven't tested any large GUI customer apps yet. Is that necessary, or is the current testing sufficient?

Please run that also.

Sure. I'll get back to you with the results as soon as the conversion is done.

#13 Updated by Octavian Adrian Gavril 20 days ago

Octavian Adrian Gavril wrote:

Sure. I'll get back to you with the results as soon as the conversion is done.

Conversion regression testing for a large GUI app also showed no differences in the generated output.

#14 Updated by Constantin Asofiei 20 days ago

  • Status changed from Internal Test to Merge Pending

11974a can be merged after 6407c

#15 Updated by Octavian Adrian Gavril 20 days ago

Rebased branch 11974a with trunk/16801. The new revision is 16802.

#16 Updated by Octavian Adrian Gavril 20 days ago

  • Status changed from Merge Pending to Test
  • version_resolved set to 16802

Branch 11974a was merged into trunk as rev. 16802 and archived.

Also available in: Atom PDF