Bug #3312
DEFINE BUFFER with TEMP-TABLE fails to resolve persistent table
0%
table_lookup.diff 
(11.6 KB)
History
#1 Updated by Hynek Cihlar almost 7 years ago
The following case fails to convert in FWD while it does work in native 4gl.
/* this assumes a default connected database with CUSTOMER table and field NAME */ DEFINE BUFFER bt FOR TEMP-TABLE Customer. FIND FIRST bt NO-ERROR. MESSAGE bt.NAME. /* << valid name is printed in 4gl */
This issue relates to #3308-261.
#2 Updated by Hynek Cihlar almost 7 years ago
When DEFINE-TABLE is present in the DEFINE BUFFER statement, it is used as a hint by the 4gl compiler to prefer a temp-table if the for-table in the statement yields a persistent and temp table. However when only persistent table is resolved the keyword doesn't prevent the compiler to use that table. See below for the possible cases.
/** the test assumes default connected database with tables ADDRESS and field STREET AS CHAR and
table BOOK with field ISBN AS CHAR */
DEFINE TEMP-TABLE Address FIELD xyz AS CHARACTER.
/** when TEMP-TABLE is present, the temp table Address is resolved */
DEFINE BUFFER bt FOR TEMP-TABLE Address.
FIND FIRST bt NO-ERROR.
MESSAGE bt.xyz.
/** when TEMP-TABLE is not present, the persistent table Address is resolved */
DEFINE BUFFER bt2 FOR Address.
FIND FIRST bt2 NO-ERROR.
MESSAGE bt2.street.
DEFINE TEMP-TABLE OnlyTemp FIELD xyz AS CHARACTER.
/** when TEMP-TABLE is present, the temp table OnlyTemp is resolved */
DEFINE BUFFER bt3 FOR TEMP-TABLE OnlyTemp.
FIND FIRST bt3 NO-ERROR.
MESSAGE bt3.xyz.
/** when TEMP-TABLE is not present, still the temp table OnlyTemp is resolved */
DEFINE BUFFER bt4 FOR OnlyTemp.
FIND FIRST bt4 NO-ERROR.
MESSAGE bt4.xyz.
/** when TEMP-TABLE is present, the persistent table Book is resolved */
DEFINE BUFFER bt5 FOR TEMP-TABLE Book.
FIND FIRST bt5 NO-ERROR.
MESSAGE bt5.isbn.
/** when TEMP-TABLE is not present, the persistent table Book is resolved */
DEFINE BUFFER bt6 FOR Book.
FIND FIRST bt6 NO-ERROR.
MESSAGE bt6.isbn.
#3 Updated by Hynek Cihlar almost 7 years ago
- File table_lookup.diff added
See the attached diff which fixes the name resolution (the diff was made against current branch 1514a). However there is a subsequent problem:
------------------------------------------------------------------------------
Code Conversion Annotations
------------------------------------------------------------------------------
Optional rule set [customer_specific_annotations_prep] not found.
./hynek/test.p
Elapsed job time: 00:00:00.839
ERROR:
com.goldencode.p2j.pattern.TreeWalkException: ERROR! Active Rule:
-----------------------
RULE REPORT
-----------------------
Rule Type : WALK
Source AST: [ bt2.street ] BLOCK/STATEMENT/KW_MSG/CONTENT_ARRAY/EXPRESSION/FIELD_CHAR/ @14:9 {12884901975}
Copy AST : [ bt2.street ] BLOCK/STATEMENT/KW_MSG/CONTENT_ARRAY/EXPRESSION/FIELD_CHAR/ @14:9 {12884901975}
Condition : javaname = p2o.javaPropertyName(getNoteString("schemaname"), false)
Loop : false
--- END RULE REPORT ---
at com.goldencode.p2j.pattern.PatternEngine.run(PatternEngine.java:1063)
at com.goldencode.p2j.convert.ConversionDriver.processTrees(ConversionDriver.java:1076)
at com.goldencode.p2j.convert.ConversionDriver.back(ConversionDriver.java:929)
at com.goldencode.p2j.convert.ConversionDriver.main(ConversionDriver.java:1950)
Caused by: java.lang.NullPointerException
at com.goldencode.p2j.schema.P2OLookup.getJavaName(P2OLookup.java:982)
at com.goldencode.p2j.schema.P2OLookup.javaName(P2OLookup.java:579)
at com.goldencode.p2j.schema.P2OLookup.javaPropertyName(P2OLookup.java:683)
at com.goldencode.p2j.schema.P2OLookup.javaPropertyName(P2OLookup.java:650)
at com.goldencode.p2j.schema.P2OAccessWorker$Library.javaPropertyName(P2OAccessWorker.java:263)
at com.goldencode.expr.CE6298.execute(Unknown Source)
at com.goldencode.expr.Expression.execute(Expression.java:373)
I am currently working on the NPE.
#4 Updated by Eric Faulhaber almost 7 years ago
Hynek Cihlar wrote:
See the attached diff which fixes the name resolution (the diff was made against current branch 1514a).
Hynek, this change looks like it could be ok, but this is a particularly tricky area of the code, so I can't tell from code review alone what the side effects might be. If it fixes the problem at hand and you get past the NPE, please apply this change tentatively to 1514a and do a conversion-only regression test against it. I'll do further testing with it overnight tonight.
#5 Updated by Hynek Cihlar almost 7 years ago
Eric Faulhaber wrote:
Hynek Cihlar wrote:
See the attached diff which fixes the name resolution (the diff was made against current branch 1514a).
Hynek, this change looks like it could be ok, but this is a particularly tricky area of the code,
Yes, the code I changed is also executed for LIKE and BEFORE-TABLE constructs. I have (passing) regression tests for these, too.
so I can't tell from code review alone what the side effects might be. If it fixes the problem at hand and you get past the NPE, please apply this change tentatively to 1514a and do a conversion-only regression test against it. I'll do further testing with it overnight tonight.
Ok. I have found the problematic code responsible for the NPE, which happens further in the ast processing. I don't have a complete fix yet but I think I am on the right track.
#6 Updated by Hynek Cihlar almost 7 years ago
The committed changes in 3312a resolve the issue only partially. There is at least one remaining problem in the AST generator.
DEFINE TEMP-TABLE Address FIELD xyz AS CHARACTER. DEFINE BUFFER bt2 FOR Address. FIND FIRST bt2 NO-ERROR. MESSAGE bt2.street.
In the example above the parser already correctly resolves the persistent table in the DEFINE BUFFER statement and the example parses without errors and exceptions, however the AST generator produces an invalid AST with TEMP-TABLE node under the DEFINE_BUFFER node. The expected AST is to have a persistent table under DEFINE_BUFFER.