FWD » Core Development » Database

Greg, the problem is that for a DEF PARAM BUFFER ... FOR some-buf statement, some-buf gets promoted because def_buf_stmt will promote a buffer for any call other than DEF BUFFER ... FOR some-buf. statement. So, when CREATE is executed, it will promote btt1 in our example, but as tt1 was promoted, too, f1 is resolved from tt1.

This patch looks like it solves the problem:

### Eclipse Workspace Patch 1.0
#P p2j6129a
Index: src/com/goldencode/p2j/uast/progress.g
===================================================================
--- workspace.java.open.client/p2j6129a/src/com/goldencode/p2j/uast/progress.g    (revision 3910)
+++ workspace.java.open.client/p2j6129a/src/com/goldencode/p2j/uast/progress.g    (working copy)
@@ -14048,12 +14048,9 @@
  * Separated from the main rule to properly build the AST without complexity.
  * This is the only reason such a simple rule is implemented separately.
  *
- * @param    promote
- *           true to force promotion of the referenced table.
- *
  * @return   The name of the first record referenced.
  */ 
-simple_for_record_spec [boolean promote] returns [String rtext = null]
+simple_for_record_spec returns [String rtext = null]
    :
       {
          NameNode nothing = null;
@ -14069,7 +14066,7 @
          :
          KW_TEMP_TAB { forceTemp = true; forcePersistent = false; }
       )?             
-      nothing = r:record[promote, false, true]
+      nothing = r:record[false, false, true]



	
{
          forceTemp = old1;
@ -14132,7 +14129,6 @
 def_buf_stmt [boolean define_stmt, boolean optionalSym, boolean importedShared, Aast am, Aast st]       
    :
{
-         boolean promote = !define_stmt;
          String rtext = null;
       }
       (
@ -14148,7 +14144,7 @
      | { optionalSym }?
               // empty alternative
          )         
-         ( options { generateAmbigWarnings = false; } : rtext=simple_for_record_spec[promote] )?
+         ( options { generateAmbigWarnings = false; } : rtext=simple_for_record_spec )?
          (
             options { generateAmbigWarnings = false; }
             :

I just disabled the 'promote' code for any kind of statement, be it a standalone buffer definition or a buffer parameter definition. Do you recall why this 'promote' was kept in the first place?

The patch is built on top of 6129b/14324.

FYI, I'm digging back through the history on this one. I'll pick it back up in the morning.

I think the intent was to promote the parameter buffer, and not the 'source' for the parameter buffer. For example, this is a compile error in OE:

procedure proc1.
   def buffer bb for book.
   message isbn.
end.

procedure proc1.
   def parameter buffer bb for book.
   message isbn.
end.

Adding promote only for parameter buffers seems to work:

### Eclipse Workspace Patch 1.0
#P p2j6129a
Index: src/com/goldencode/p2j/uast/progress.g
===================================================================
--- workspace.java.open.client/p2j6129a/src/com/goldencode/p2j/uast/progress.g    (revision 3910)
+++ workspace.java.open.client/p2j6129a/src/com/goldencode/p2j/uast/progress.g    (working copy)
@@ -14048,12 +14048,9 @@
  * Separated from the main rule to properly build the AST without complexity.
  * This is the only reason such a simple rule is implemented separately.
  *
- * @param    promote
- *           true to force promotion of the referenced table.
- *
  * @return   The name of the first record referenced.
  */ 
-simple_for_record_spec [boolean promote] returns [String rtext = null]
+simple_for_record_spec returns [String rtext = null]
    :
       {
          NameNode nothing = null;
@ -14069,7 +14066,7 @
          :
          KW_TEMP_TAB { forceTemp = true; forcePersistent = false; }
       )?             
-      nothing = r:record[promote, false, true]
+      nothing = r:record[false, false, true]



	
{
          forceTemp = old1;
@ -14132,7 +14129,6 @
 def_buf_stmt [boolean define_stmt, boolean optionalSym, boolean importedShared, Aast am, Aast st]       
    :
{
-         boolean promote = !define_stmt;
          String rtext = null;
       }
       (
@ -14148,7 +14144,7 @
      | { optionalSym }?
               // empty alternative
          )         
-         ( options { generateAmbigWarnings = false; } : rtext=simple_for_record_spec[promote] )?
+         ( options { generateAmbigWarnings = false; } : rtext=simple_for_record_spec )?
          (
             options { generateAmbigWarnings = false; }
             :
@ -14178,7 +14174,7 @


	
// imported (non-new) shared buffers are the equivalent of a FIND or CREATE, we must
             // promote these buffers to ensure proper name disambiguation
-            if (importedShared)
+            if (importedShared || !define_stmt)
{
                // not sure about the noProp flag here
                sym.promoteTableName(#b.getText(), true, false);

The change was introduced in trunk revision 4785:

** 128 ECF 20060818 CHG   @28686 Added boolean parameter to record rule. If
**                               true, record's table is promoted, else not.

I'm still trying to relate this back to the original task/bug it was meant to fix. The JPRM number 28686 does not appear in Redmine. I see some possible tasks from that same time period which could maybe be related: #346 and #347.

There is no change in the application used for task #346. In the customer's app, all changes look 'expected', the parameter buffer is used instead of the implicit one.

I've committed this change to 6129b/14327.

In the end there was no information in email, testcases/uast/, Redmine or bzr that could lead be back to the original reason for the change in rev 4785.

The whole "promote" concept with the SchemaDictionary is just a hack/workaround to simulate the buffer scoping at parse time which we calculate much later (in annotations). It doesn't match 1 for 1 with the proper buffer scoping, so this is really a nasty area where we have built patch on patch on patch. Since we have no proper testcases for checking this (yet), we can only go by th elogic of the change and the affect it has on the converted code.