Bug #2059: CAN-FIND clause for a perm table in the RECORD_PHRASE of a temp table, with a FOR EACH statement - Database - Golden Code Redmine

Bug #2059

CAN-FIND clause for a perm table in the RECORD_PHRASE of a temp table, with a FOR EACH statement

Added by Constantin Asofiei about 11 years ago. Updated over 7 years ago.

Status:

Closed

Priority:

Normal

Assignee:

Constantin Asofiei

Target version:

FWD - Conversion Support for Server Features

Start date:

02/26/2013

Due date:

% Done:

100%

billable:

vendor_id:

GCD

case_num:

ecf_upd20130303b.zip (4.63 KB) Eric Faulhaber, 03/03/2013 03:22 PM

ecf_upd20130312a.zip (12.1 KB) Eric Faulhaber, 03/12/2013 12:14 PM

History

#1 Updated by Constantin Asofiei about 11 years ago

Status changed from New to WIP

The following code fails at conversion time:

def temp-table wf1 field f1 as int.
for each wf1 where wf1.f1 > 0 or can-find(person where person.emp-num = wf1.f1) no-lock:

end.

EXPRESSION EXECUTION ERROR:
---------------------------
uberref.graft(uberdupref)
        ^  { java.lang.NullPointerException }
---------------------------
ERROR:
java.lang.RuntimeException: ERROR!  Active Rule:
-----------------------
      RULE REPORT      
-----------------------
Rule Type :   ASCENT
Source AST:  [ record phrase ] BLOCK/INNER_BLOCK/KW_FOR/RECORD_PHRASE/ @0:0 {12884901914}
Copy AST  :  [ record phrase ] BLOCK/INNER_BLOCK/KW_FOR/RECORD_PHRASE/ @0:0 {12884901914}
Condition :  uberref.graft(uberdupref)
Loop      :  false
--- END RULE REPORT ---

    at com.goldencode.p2j.pattern.PatternEngine.run(PatternEngine.java:732)
    at com.goldencode.p2j.convert.ConversionDriver.processTrees(ConversionDriver.java:948)
    at com.goldencode.p2j.convert.ConversionDriver.back(ConversionDriver.java:836)
    at com.goldencode.p2j.convert.ConversionDriver.main(ConversionDriver.java:1729)
Caused by: com.goldencode.expr.ExpressionException: Expression execution error @1:9 [RECORD_PHRASE id=12884901914]
    at com.goldencode.p2j.pattern.AstWalker.walk(AstWalker.java:226)
    at com.goldencode.p2j.pattern.AstWalker.walk(AstWalker.java:160)
    at com.goldencode.p2j.pattern.PatternEngine.apply(PatternEngine.java:1119)
    at com.goldencode.p2j.pattern.PatternEngine.processAst(PatternEngine.java:1017)
    at com.goldencode.p2j.pattern.PatternEngine.run(PatternEngine.java:704)
    ... 3 more

#2 Updated by Eric Faulhaber about 11 years ago

File ecf_upd20130303b.zip added

The attached update is an interim workaround to protect against the NPE so we can get further into conversion. Still working on a proper fix.

This has passed conversion regression testing and is committed to bzr rev. 10236.

#3 Updated by Constantin Asofiei about 11 years ago

Eric, your fix in SchemaDictionary I don't think it works for temp-tables, as the following code:

def temp-table real      field f1 as char.
def temp-table conflict  field f1 as char.
def temp-table container field num as int.

produces these scopes:

the schema global scope, where the emp-num appears twice, in pers-addr and person (OK)
the user global scope, which contains only these: {0=null, 1=[conflict, real], 2=[conflict.f1]}. Note how the real.f1 field is omitted.

I think there is a bug for the user global scope, on SchemaDictionary.addEntry:3119. This should be:

         boolean schemaScope = (scopes.size() - 1 == SCHEMA_GLOBAL_SCOPE) || 
                               (scopes.size() - 1 == USER_GLOBAL_SCOPE);

#4 Updated by Constantin Asofiei about 11 years ago

LE: actually, I think the correct test is:

boolean schemaScope = (scopes.size() - 1 == SCHEMA_GLOBAL_SCOPE) || globalScope;

#5 Updated by Eric Faulhaber about 11 years ago

Good point. Actually, the best is probably just to get rid of the schemaScope variable altogether and use the globalScope parameter in its place. I guess that's really what I was trying to accomplish in the first place, but it's been so long since I was in this code.