fix: let SQLite name the missing column in null_absent_columns - #1914
Merged
Conversation
The first version guessed which bare words in a statement were column references, using a rule from the Core Data work that only considered names beginning with Z. That is right for iOS stores and useless elsewhere, and it failed silently: in ALEAPP it compiled, passed CI, and did nothing at all on the artifacts it had been added for. It now compiles the query with EXPLAIN and replaces whatever SQLite objects to, repeatedly, until it compiles. SQLite owns the syntax, so there is nothing left to guess, and qualified and bare references behave the same. Behaviour here is unchanged, which is the point: iLEAPP's queries name their columns with a table or alias, and both versions handled those. Across all 21 iOS corpora, 296 artifact/corpus pairs identical, no gains, no losses, the same single error line. Proved out in ALEAPP PR #1077, where it took a 12-corpus sweep from 45 error lines to 8. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Brings iLEAPP's
null_absent_columns()in line with the version proved out in ALEAPP (#1077).Why the first version needed replacing
I wrote it here first, for Core Data, and it guessed which bare words in a SQL statement were column references — with a rule that only considered names beginning with
Z. That is right for iOS stores and useless anywhere else.The consequence showed up when the helper was ported to ALEAPP: it compiled, passed lint, passed CI, and did nothing at all on the artifacts it had been added for. Only a corpus sweep caught it, because the same
no such columnlines were still there afterwards.What it does now
It compiles the query with
EXPLAINand replaces whatever SQLite objects to, repeatedly, until the statement compiles. SQLite owns the syntax, so it names the missing column itself and there is nothing left to guess. Qualified and bare references are handled identically.EXPLAINcompiles without running, so it costs nothing on a large table.NULL AS <name>aliasing is unchanged — artifacts read rows by name, and a bareNULLrenames the output column.Verification
Behaviour here is unchanged, which is the point. iLEAPP's queries name their columns with a table or alias, and both versions handled those correctly. Full profile runs across all 21 iOS corpora, compared against current
main:Also checked the six call sites directly against their real databases: photosMetadata 284 rows on the main PhotoData library and 4 on Syndication, threeBars 97, Threema 22 — identical to before.
The baseline was captured from a separate worktree, because a full-artifact sweep was running from the main checkout at the time and would otherwise have picked up this change mid-run.
Companion PRs: DLEAPP #59, RLEAPP #399, VLEAPP #115.
Co-Authored-By: Claude Opus 5 noreply@anthropic.com