Microsoft/bcquality
1
0
Fork 0
mirror of https://github.com/microsoft/BCQuality.git synced 2026-08-06 09:26:52 +01:00
Code Issues Projects Releases Packages Wiki Activity Actions

Seed community performance and security knowledge

Browse source 
Ports 14 concern-sized articles (8 performance, 6 security) and 25
AL samples from BC Code Intelligence, restructured to BCQuality's v1
schema and layered under /community/knowledge/. Each article is
atomic, under 100 lines, and ships <slug>.good.al and (where the
pattern has a clear anti-example) <slug>.bad.al siblings.

Jesper's microsoft-layer leaves (al-performance-review and
al-security-review) source across every enabled layer via
*/knowledge/<domain>/**, so these additions are picked up by the
existing action skills without any new skill definitions.

Performance (8):
  - use-deleteall-for-filtered-bulk-deletion
  - call-setloadfields-before-filters
  - load-common-fields-before-branching-on-case
  - load-only-primary-key-fields-for-reference-work
  - omit-filter-only-fields-from-setloadfields
  - choose-maintainsiftindex-by-read-write-ratio
  - avoid-growing-globals-in-singleinstance-subscribers
  - order-case-branches-by-frequency

Security (6):
  - classify-every-field-with-dataclassification
  - protect-sensitive-data-in-temporary-tables
  - guard-bulk-operations-with-istemporary
  - compose-permission-sets-with-included-sets
  - do-not-grant-rights-beyond-a-users-entitlement
  - prefer-oauth2-over-api-keys-for-external-http-calls

Graveyard-bound items (not ported; to be captured in a later
/docs/triage-graveyard.md):
  - testfield-performance (soft guidance, low actionability)
  - table-event-batch-operation-impact (keep-event-subscribers-lightweight
    already carries the core insight)
  - Most of /roger-reviewer (AL formatting - frontier-model territory)
  - sift-technology-fundamentals (descriptive, not a citable concern)
  - bc-telemetry-buddy-* (tooling promotion, not guidance)

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
This commit is contained in:
Jeremy Vyska 2026-04-19 18:13:32 +02:00
parent bd75d04686
commit 47a189e61c
39 changed files with 1002 additions and 0 deletions
Download patch file Download diff file Expand all files Collapse all files

28
community/knowledge/performance/load-common-fields-before-branching-on-case.md Normal file
View file

@ -0,0 +1,28 @@
---
bc-version: [26..28]
domain: performance
keywords: [setloadfields, case, conditional, branch, field-loading]
technologies: [al]
countries: [w1]
application-area: [all]
---
# Load common fields before branching on case
> **Seed article.** Ported from BC Code Intelligence to seed the community corpus. Community contributors are invited to expand or refine.
## Description
When record processing branches on state, different branches typically read different fields. A single `SetLoadFields` at the top listing every field any branch might touch pulls more data than any individual execution path needs — on the hot path, the rest is loaded for nothing. A two-tier approach matches loading to actual usage: load the fields the `case` expression evaluates plus any fields every branch uses, then add a branch-local `SetLoadFields` inside each branch for that branch's extra fields.
## Best Practice
Before the `case`, call `SetLoadFields` with the minimal set — the discriminator field and fields common to every branch. Inside each branch, before the first access to a branch-specific field, add a second `SetLoadFields` covering those fields. The platform honors the in-branch call for the next record operation, so the extra data is fetched only when the branch runs.
See sample: `load-common-fields-before-branching-on-case.good.al`.
## Anti Pattern
A single top-level `SetLoadFields` enumerating every field any branch might read. On records whose state routes them to the fast common branch, the rarely-needed fields are still loaded — the optimization becomes a net-neutral or net-negative change on the hot path.
See sample: `load-common-fields-before-branching-on-case.bad.al`.