Bug #2034
correct conversion of CAN-FIND({FIRST|LAST} ... {SHARE-LOCK|EXCLUSIVE_LOCK} [NO-WAIT])
0%
Related issues
History
#1 Updated by Eric Faulhaber about 11 years ago
Currently, we convert CAN-FIND({FIRST|LAST} ...)
with a lock the same as we do as if it doesn't have a lock; that is, to use FindQuery.hasAny()
. In the locking case, however, hasAny
is not specific enough, because we have to test whether the particular, found record could be locked. So, we need to add hasFirst
and hasLast
for the locking case.
#2 Updated by Eric Faulhaber about 11 years ago
- Target version changed from Milestone 7 to 24
On second thought, as long as the sort phrase is correct, hasAny
will find the correct first or last record. So, rather than adding hasFirst
and hasLast
, we should invert the sort phrase in cases of FIND LAST and leave it alone in cases of FIND FIRST, and hasAny
will work as is. In other words, the current runtime should be OK; this would require only a conversion change.
There are no cases of FIND LAST ... {SHARE|EXCLUSIVE}-LOCK in the current (server) project, so the current conversion (by happy accident) works correctly.
We may need to revisit this for the gui project, and anyway a more correct solution is to invert the sort phrase for FIND LAST in all cases (even NO-LOCK). Note that this change may have performance implications for databases which cannot identify an index to use for the query when the sort phrase is inverted.
#3 Updated by Greg Shah over 7 years ago
- Target version deleted (
24)