Bug #2057: buffer unique name disambiguation (separator problems) - Database - Golden Code Redmine

Bug #2057

buffer unique name disambiguation (separator problems)

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:

ca_upd20130226d.zip (8.4 KB) Constantin Asofiei, 02/26/2013 02:13 PM

History

#1 Updated by Constantin Asofiei about 11 years ago

We have a case where an existing buffer defined for a table, like:

def buffer b-person for person.

is identified as the original buffer for a field reference of a statement like:

procedure proc0.
   for each pers-addr where pers-addr.emp-num = person.emp-num:
   end.
end.

where we get something like:

for the reference inside the procedure, dbname.person_dbname.person
for the b-person buffer, dbname.b-person_dbname.person
In BufferScopeWorker.getBuffer, when the matching for dbname.person is done after the "_" char, it will identify b-buf, when really doesn't exist a buffer for it.

The hard part of duplicating this was that the default test database, p2j_test, contains an underscore in its name, thus matching is not done properly.
This issue is in two parts:

find and fix why person is matched with b-person
do not allow the dbname to contain an underscore, or improve the "_" separator part (in buffer unique name) to use something more exotic (maybe multiple chars?)

#2 Updated by Eric Faulhaber about 11 years ago

I realize you're the assignee for this, but it looked like it might be related to what I fixed last night, so I converted the test code you posted.

When you say, "the hard part of duplicating this...", are you saying that the above test code does not duplicate the problem? The code converts OK for me.

#3 Updated by Constantin Asofiei about 11 years ago

Eric, the code converts because our test db is named "p2j_test", with an underscore... I had to change the DB name to "p2jtest" do duplicate it. Using underscore as separator was unfortunate...

#4 Updated by Constantin Asofiei about 11 years ago

Eric, one more question: if you can, please explain why BufferScopeWorker.getBuffer attempts to match the buffer using "dbname.targettable" (without the explicit name set), after the matching after "explicitname_dbname.targettable" has provided no results. Because I can't see any reason why two explicitly defined buffers would act the same. For me, the solution would be to let BufferScopeWorker.getBuffer match only after the "." and not the "_".

#5 Updated by Constantin Asofiei about 11 years ago

File ca_upd20130226c.zip added

Update: with the BuffescScopeWorker.getBuffer changed I mentioned earlier, conversion of app folder goes through all files OK.

I did not conversion regression tested it yet.

#6 Updated by Eric Faulhaber about 11 years ago

Constantin Asofiei wrote:

Eric, one more question: if you can, please explain why BufferScopeWorker.getBuffer attempts to match the buffer using "dbname.targettable" (without the explicit name set), after the matching after "explicitname_dbname.targettable" has provided no results. Because I can't see any reason why two explicitly defined buffers would act the same. For me, the solution would be to let BufferScopeWorker.getBuffer match only after the "." and not the "_".

I explicitly put this more lenient level of matching in to fix some defect in Majic in 2006 (H002), so taking it out now makes me a bit nervous. Please run conversion with your fix against Majic to see if it breaks anything.

#7 Updated by Constantin Asofiei about 11 years ago

The conversion regression testing has passed, the only diffs were related to instance field order (RecordBuffer.define lines) in the class associated with the external program and a reordering of buffers in the RecordBuffer.openScope calls - this has no impact in runtime.