Parity: refresh for the type-handler decision, and put the delta up front - #210
Merged
Conversation
…ront parity.md still described type handlers as an open unification question, and still claimed DAP050 was the next free id. Both moved: #208 shipped declarative registration, and DAP050-055 are now taken. The type-handler row splits in two, because the answer was different for each half: declaring a handler is supported (and a vanilla SqlMapper.ITypeHandler can be named as-is, adapted by a generated shim), while registering one at runtime is now an explicit non-goal with the reasoning recorded. XML types, UDTs and bare DataTable members move from "not supported" to "expressible, no built-in declaration shipped" - which is a different question and a much smaller one. Adds a delta summary at the top so the file answers "what is actually left" without reading five tables: the corpus number, the interception ratio, and the remaining work ordered by weight, including which items are corpus adoption rather than product work, and the two type-handler ceilings that will not convert at all.
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.
parity.mdhad gone stale: it still described type handlers as an open unification question ("how does a Dapper handler registration become an AOT one?"), and still said DAP050 was the next free diagnostic id. #208 answered the first; DAP050–055 are now taken.The type-handler row splits in two, because the answer differs by half — declaring a handler is supported, and a vanilla
SqlMapper.ITypeHandlercan be named as-is because generated code adapts it; registering one at runtime is now an explicit 🚫 with the reasoning recorded inline (hot-path cost for everyone, unverifiable at build,TypeHandlerCache<T>is unresolvable by ILC — issue #165).XML types, UDTs and bare⚠️ : all three are expressible today by declaring a handler. The open question is now only whether we ship built-in declarations for the types vanilla registers by default — a much smaller question than the one those rows described.
DataTablemembers move from ❌ toA delta summary goes at the top, so the file answers "what is actually left" without reading five tables: 677/793 on the corpus, 533/725 intercepted, and the remaining work ordered by weight — multi-map and GridReader first, then corpus adoption of
[TypeHandler], literals, the coercion tail,ExecuteReader, announced types, and the singles. It also records which items are corpus adoption rather than product work, and the two type-handler cases that will never convert (a test that registers a specific instance and asserts on it, andResetTypeHandlers/RemoveTypeMap, which are runtime map mutation).Notes only — no code changes.