Bug #10307
FFcache keys don't match for the values inlined vs passed as args
0%
Related issues
History
#1 Updated by Andrei Plugaru about 1 year ago
While working on #8279, found a scenario where the a record wasn't retrieved from the FF cache, even though it should have:
DEF TEMP-TABLE tt1 FIELD id AS INT FIELD c AS CHAR. DEF TEMP-TABLE tt2 FIELD id AS INT FIELD c AS CHAR FIELD d AS CHAR index idx as unique id. CREATE tt1. tt1.id = 1. tt1.c = 'a'. CREATE tt2. tt2.id = 1. tt2.c = 'a'. tt2.d = 'a'. RELEASE tt1. RELEASE tt2. def var x as int. x = 1. find first tt2 where tt2.id = x. message tt2.id. find first tt2 where tt2.id = x. // found in FF cache message tt2.id. find first tt2 where tt2.id = 1. // not found in FF cache message tt2.id.
Basically the FFcache keys for tt2.id = x and tt2.id = 1 are different even though they should match the same records. At a first glance, I would think that the args should be inlined into the where clause.
#2 Updated by Artur Școlnic 12 months ago
- Related to Bug #10362: FastFindCache.L2Key uses the buffer alias in the FQL added
#3 Updated by Andrei Plugaru 12 months ago
I did put a little thought into how we can inline the arguments into the fql in order to match the FFcache keys for the example from #10307-1. A clean approach would be to create an FQLPreprocessor with inline set on true. However, during my testing, this didn't behave as expected, the arguments were still not inlined. Another approach would be to manually modify the fql String and replace the ? placeholders with the actual values. However, both these approaches don't seem performant and I would think that the benefit gained by using the ffcache in these situations will be heavily offset by the processing needed by these additional operations.
I am open to other suggestions.