bcquality/microsoft/knowledge/performance/prefer-get-for-primary-key-lookups.md
Jesper Schulz-Wedde 9a4198eb28 Add [all] sentinel to bc-version; apply to version-agnostic knowledge
Most of the corpus — FindSet/SetLoadFields/CalcFields patterns, permission
sets, SingleInstance codeunits, DataClassification, IsolatedStorage,
transaction scope, SecretText — describes BC platform behaviour that is
identical across supported versions. The seed [26..28] range on every
file implied a version-specificity the content does not actually have,
and there was no way to express "applies to every version" in the
schema the way [w1] and [all] already do for countries and
application-area.

Extend the v1 schema with a universal sentinel for bc-version, parallel
to the sentinels already defined for the other dimensions:

  bc-version: [all]         # applies to every BC version

[all] is mutually exclusive with explicit versions. Range shorthand
([26..28]) and explicit lists ([26, 27, 28]) continue to work for files
genuinely tied to a version-gated API or deprecation.

Update read.md (field definition, matching semantics, partial-context
rule), write.md (default to [all], use ranges only with a concrete
reason), README.md (frontmatter example), and the CI validator. All
forty existing knowledge files and the three action skills convert to
[all]; none of the current content is version-gated. Validator passes.
2026-04-23 16:00:03 +02:00

1.1 KiB

bc-version domain keywords technologies countries application-area
all
performance
get
findfirst
primary-key
lookup
al
w1
all

Prefer Get for primary-key lookups

Seed article. Converted from an existing performance-review prompt to bootstrap the BCQuality performance corpus. Domain stewards should expand, restructure, and refine as needed.

Description

Get is a direct primary-key lookup: one index seek, one row, done. FindFirst with SetRange on the primary key fields reaches the same row through a more general code path and carries the overhead of filter setup and a broader optimizer decision.

Best Practice

When the complete primary key is known, call Get. Use FindFirst only for non-primary-key lookups or when the filter is a partial prefix of the key.

See sample: prefer-get-for-primary-key-lookups.good.al.

Anti Pattern

Setting one SetRange per primary-key field and then calling FindFirst reproduces Get with more typing and slightly worse performance.

See sample: prefer-get-for-primary-key-lookups.bad.al.