FWD » Core Development » Database

Please review the following articles:

http://knowledgebase.progress.com/articles/Article/000032702
https://community.progress.com/community_groups/openedge_general/f/26/t/12020
http://knowledgebase.progress.com/articles/Article/P39990
http://stackoverflow.com/questions/18267870/static-vs-dynamic-queries-in-openedge

Of interest is that static queries can have their WHERE clause and BY clause modified dynamically.

On a positive note, the buffer(s) can't be changed.

This code generates a NPE on trunk-11347:

def temp-table tt1 field f1 as int index ix1 is unique f1.
def var h as handle.

def query q1 for tt1.
h = query q1:handle.
message "S1" h:num-buffers h:is-open h:dynamic.
open query q1 for each tt1 no-lock.
message "S2"  h:num-buffers h:is-open h:dynamic.
h:query-prepare("for each tt1 no-lock indexed-reposition").
message "S3"  h:num-buffers h:is-open h:dynamic. // 1 no no FWD abends

h:query-prepare("for each tt1 where f1 = '' no-lock indexed-reposition").
message "S4"  h:num-buffers h:is-open h:dynamic. // 1 no no FWD abends

/*
We need some more tests to see how the static query q1 gets affected 
if its query predicate is changed to something else, like adding a 
WHERE clause, another buffer, etc.
*/

create query h.
h:add-buffer(buffer tt1:handle).
h:query-prepare("for each tt1 no-lock indexed-reposition").
message "D1" h:num-buffers h:is-open h:dynamic.

Will there be different code-paths for a temp-table versus a standard table? I am walking through the testcase, trying to get familiar with the life-cycle of the predicate/buffers.

Stack trace?

Nevermind, got it.

Caused by: java.lang.NullPointerException
        at com.goldencode.p2j.persist.PreselectQuery.getTableCount(PreselectQuery.java:3515)
        at com.goldencode.p2j.persist.AbstractQuery.numBuffers(AbstractQuery.java:3036)
        at com.goldencode.p2j.persist.QueryWrapper.numBuffers(QueryWrapper.java:5456)
        at com.goldencode.testcases.DynStatQry.lambda$execute$0(DynStatQry.java:58)
        ...

Eric Faulhaber wrote:

Nevermind, got it.

Are you looking at this? Did you see the notes in #4208-736 ?

Eric Faulhaber wrote:

Yes and no :-)

I am attaching a patch because I didn't have a branch to which to commit. The attached patch fixes the NPE, but it needs review by someone more familiar with the dynamic query implementation.

The core problem is that QueryWrapper is determined to be dynamic or static at construction, and any assignment of a delegate query of the opposite nature later does not update this state. This leads to incorrect handling of API calls that assume a static query when a dynamic one has been assigned, and presumably vice-versa. My fix updates the state of the dynamic flag to true when a dynamic query is assigned to the wrapper.

The fix is not orthogonal and maybe it should be, in the event a wrapper assigned dynamic at construction can be assigned a static delegate query later.

Constantin, please take it from here.

• "Unable to PREPARE TEMP-TABLE buffer object. (9046)"
• "TEMP-TABLE must be PREPARED before referencing NAME/DEFAULT-BUFFER-HANDLE etc. (9040)"

Roger Borrello wrote:

That patch alleviated the NPE, and we now result in:

• "Unable to PREPARE TEMP-TABLE buffer object. (9046)"
• "TEMP-TABLE must be PREPARED before referencing NAME/DEFAULT-BUFFER-HANDLE etc. (9040)"

Are you using a different test case? I didn't get those errors.

Eric Faulhaber wrote:

Constantin, please take it from here.

OK, I'm working on it.

Eric Faulhaber wrote:

I am attaching a patch because I didn't have a branch to which to commit. The attached patch fixes the NPE, but it needs review by someone more familiar with the dynamic query implementation.

We can't make a static query resource dynamic. The query resource is still reported as 'non-dynamic', even if its delegate was changed via query-prepare (and the delegate is dynamic).

... in the event a wrapper assigned dynamic at construction can be assigned a static delegate query later.

I don't think so. 4GL doesn't allow access to the underlying actual query (the delegate in FWD). Only the query resource can be moved from a handle to another, and all access is done through this resource.

I think my idea with the dynamicDelegate will work, but I need to check all the 'dynamic' behavior with a static query resource. And how the static query behaves once it was prepared with a dynamic delegate.

Roger, the fix is in 3821c rev 11363.

Please test with the customer scenario.

Constantin Asofiei wrote:

Roger, the fix is in 3821c rev 11363.

Please test with the customer scenario.

I'll let you know.

Roger Borrello wrote:

Constantin Asofiei wrote:

Roger, the fix is in 3821c rev 11363.

Please test with the customer scenario.

I'll let you know.

The NPE is gone. I'll post to #4208 for customer details. I'll proceed with debugging that application.