You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Refactor frontline database layer and add SQL query documentation (#5288)
* refactor: copy new mysql package
* fix: generate into new mysql package
* refactor: move frontline queries
* optimize frontline database
* fix: remove wrong index
* chore: clean up indices
some were also uncommented for no reason, I have checked the db
* docs: make sql comments more helpful and less verbose
* Update dev/k8s/manifests/frontline.yaml
Co-authored-by: coderabbitai[bot] <136622811+coderabbitai[bot]@users.noreply.github.com>
* Update svc/frontline/config.go
Co-authored-by: coderabbitai[bot] <136622811+coderabbitai[bot]@users.noreply.github.com>
---------
Co-authored-by: coderabbitai[bot] <136622811+coderabbitai[bot]@users.noreply.github.com>
**Context**: Document context behavior only if it is non-standard.
153
156
157
+
## SQL query documentation
158
+
159
+
Named SQL queries are part of the public contract between application code and the database. Treat query comments like API documentation.
160
+
161
+
For SQL query docs, explain why this query exists, how it resolves non-obvious behavior, and what guarantees callers can rely on. Do not just restate the `SELECT` clause.
162
+
163
+
Keep SQL comments concise. In most cases, two to five lines are enough. If a comment is longer than the query, each sentence must carry non-obvious information such as fallback guarantees, deterministic ordering, intentional join behavior, or performance tradeoffs.
164
+
165
+
Avoid duplicate explanations. If the SQL already makes behavior obvious, for example `AND s.health = 'healthy'`, do not repeat that in prose unless you are documenting a non-obvious guarantee that depends on it.
166
+
167
+
For selection queries with fallback logic, document deterministic behavior explicitly. If exact matching must win over wildcard matching, explain how SQL enforces it, for example with `ORDER BY` and not candidate list order.
168
+
169
+
For query docs that are not obvious from a quick read, include a small concrete example with inputs and the expected returned row. This is required for logic that depends on ordering, fallback, or tie-breaking.
170
+
171
+
Document performance-sensitive choices when they are intentional, for example using `LIMIT 1` to avoid transferring large payload rows that are not selected.
172
+
173
+
```sql
174
+
-- name: FindBestCertificateByCandidates :one
175
+
-- FindBestCertificateByCandidates returns one certificate row for the provided
176
+
-- hostnames, preferring an exact hostname over wildcard matches.
177
+
-- MySQL does not preserve IN-list order, so exact-first behavior is enforced by
178
+
-- ORDER BY against exact_hostname, not by candidate position.
179
+
--
180
+
-- Example: with candidates ['api.example.com', '*.example.com'] and
181
+
-- exact_hostname 'api.example.com', this query returns 'api.example.com' when
182
+
-- both rows exist. If only '*.example.com' exists, it returns the wildcard row.
Do not document implementation details in doc comments. Those belong inside the function. Do not explain that context is used for cancellation or mention O(1) performance unless it is surprising.
0 commit comments