Project

General

Profile

Bug #2034

correct conversion of CAN-FIND({FIRST|LAST} ... {SHARE-LOCK|EXCLUSIVE_LOCK} [NO-WAIT])

Added by Eric Faulhaber about 11 years ago. Updated over 7 years ago.

Status:
New
Priority:
Normal
Assignee:
-
Target version:
-
Start date:
Due date:
% Done:

0%

billable:
No
vendor_id:
GCD
case_num:
version:

Related issues

Related to Database - Bug #3040: CAN-FIND issues New

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)

Also available in: Atom PDF