FWD » Core Development » Database

There are some opportunities to short-circuit the CAN-FIND query in FWD. A CAN-FIND statement is relaxed, in the sense that it shouldn't update the buffer, throw persistence errors or lock records. Please read the CAN-FIND documentation before moving on with this to ensure that short-circuiting doesn't skip any important step in the way.

Right now, a CAN-FIND is resolved through a RandomAccessQuery. It either uses the ffCache or executes an SQL query. Note that CAN-FIND can state a where clause and can be ANY (does the table have at least one record?) or ONE (does the table have exactly one record?). Please use 7026a for now, to have access to the latest changes regarding direct-access.

• Simply return false if the buffer is backed by a definitely empty table. This is already handled in the provided patch.
• Simply return true if the buffer is backed by a definitely non-empty table, it doesn't have a where clause and is ANY.
• Use the FQLPreprocessor to detect if this is a findByRowId or findByUniqueIndex query. If so, use ANY instead of ONE. I guess ANY is wider and, thus, faster. Check if this is the case.
• Consider extending direct-access technique (RandomAccessQuery.executeDirectAccess) to cover some specific use-cases.

I am still in the process of debugging some large-customer applications to make a statistic of how many simple queries are executed and how they look like.

There is an improvement when using ANY instead of ONE for persistent tables when a findByUniqueIndex is detected. The rest of the results don't have a high margin, except the +11% when using ANY for temp-tables.

• The first optimization for empty tables is not caught by your tests - you mention "10k records" per table.
• I don't know if the second optimization is hit; are you testing with no where clauses to match the no constraint precondition?
• The latest optimization converts ONE to ANY where possible. In your tests, ANY is always faster than ONE, so it is a good optimization overall.

I think your <10% rates are error thresholds, considering that the first two optimizations are not hit. Correct me if I am wrong.

Review of 7026b/rev. 14502

• Danut, please update the copyright each type you are modifying a file (i.e. RandomAccessQuery). Also, update the # in history entry if the changes come from another branch then the previous entry. In your case, this is the first entry on RandomAccessQuery from 7026b.
• Move canFindMode = = CanFind.ANY to be the first clause in your guard. It is the fastest and has a good variance comparing to the other clauses (buffer.isTemporary() && !hasConstraints()).
• buffer.isTemporary is a bit confusing as it is not equivalent to our intent: "the table is not empty" (even if conceptually isTableDefinitelyEmpty was already used). Please create a definitelyHasRecords. Make it return false for RecordBuffer and !isTableDefinitelyEmpty() for TemporaryBuffer. This way, we can replace buffer.isTemporary to buffer.definitelyHasRecords/
• It is best to add a canFindMode == CanFind.ONE to the helper.getFQLPreprocessor().isUniqueFind(true) guard. I see a lot of hits here updating canFindMode to ANY, even if it was already set on ANY.

Tested 7026b/rev. 14503 and got -1.8% improvement overall.
There was no regression in the POCs I tested.

This was merged in trunk as rev. 14523 and can be closed.