FWD » Core Development » Database

Needs research: is it just a handle or is there some special DB processing needed at the transition point?

Does it include TABLE-HANDLE parameters?

Yes.

Eric, I'm still investigating the question in order to provide exact list of required changes, but at this point it is obvious that:

for TABLE parameters:
- Append on the calling side doesn't work (but conversion part is OK).
- Constraints violation error on table append doesn't handled properly.

TABLE-HANDLE parameters are NOT supported at runtime.
- Passing a handle for static tables shouldn't be a problem.
- For dynamic tables we have to implement runtime part, i.e. create a copy of the passed table and copy data if necessary from/to the source table.
- Problems inherited from the TABLE parameter issues.

For M7 we have to implement table-handles for static tables, append on both sides. I guess fixing constraints violation also should be done.
I'm trying to figure out if we should implement table-handle for dynamic tables, it is the most resource-demanding part.

I've found cases where dynamic tables are passed, so all problems noted above should be fixed. And I need to finish the extensive set of testcases.
Should I work on the issues after the testcases will be finished?

Yes.

Eric, TemporaryBuffer.copyAlRows which is supposed to perform record copy upon calling a procedure which uses TABLE/TABLE-HANDLE parameters doesn't work for extents. Basically, at this point we cannot determine original field order when it comes to extents. E.g.

def temp-table tt1 field f1 as integer extent 3
                   field f2 as integer extent 3
                   field f3 as char.

def temp-table tt1 field f1 as integer extent 3
                   field f3 as char
                   field f2 as integer extent 3.

We already have an annotation like this for #2134, but currently it is only for extent fields which have been expanded with custom hints. You can adapt this according to your needs. If you take part of the code from that issue and integrate it here, please notify Vadim accordingly.

In general, I am OK with your approach, BUT, we need to have the primary functionality for this issue tested and checked in before you leave for vacation. If this piece (which is somewhat of an edge case, but possibly in use) has to wait until you get back, that is preferable to delaying the primary functionality.

Eric, please consider OUTPUT TABLE-HANDLE parameters, like this:

define output parameter table-handle th.
...
th = temp-table some-table:handle.

Stanislav Lomany wrote:

[...]
The ideas that I have:
1. Create prioritized finalizables.
2. Track all static table scoped to the same external procedure.
3. Technically finalizables are stored in the list so if I move TemporaryBuffer.createDynamicTable call (kind of associate for table handles) before openScope calls it will work.
Any ideas?

I guess I like option 3, as it is least invasive (does not require additional data structures to be maintained). However the javadoc for TransactionManager's finalizable registration methods does not make explicit the contract about the order in which notifications are performed with respect to the order in which objects are registered. Since you are now relying on behavior which is otherwise encapsulated in the TM, please update the javadoc accordingly, so this contract is explicit and can be relied upon by clients of TM.

• I was a bit confused by the deferred copy error processing in TemporaryBuffer, with the corresponding change in TM. Please explain the reason this is needed.

This code is intended to avoid unnecessary logging if a copy error occurs. If logging is OK then I can just throw an exception which will be caught in TM.processFinalizables.

Issue noted in note 4 in #2207 also affects table parameters. The only difference is that the records can't be partially copied, so the copy order doesn't matter. Testcase:
test.p:

def temp-table tt 
     field f1 as integer
     field f2 as integer
     index idx1 is unique f1.

create tt.
tt.f1 = 55.
tt.f2 = 55.

run test2.p (output table tt append) no-error.

form tt with frame f1 10 down.
for each tt:
   display tt with frame f1.
   down with frame f1.
end.

test2.p:

def temp-table tt 
     field f1 as integer
     field f2 as integer.

def output parameter table for tt.

create tt.
tt.f1 = 1.
tt.f2 = 3.

create tt.
tt.f1 = 1.
tt.f2 = 4.

Also, NO-ERROR option is not properly handled.