Oops.

1 files changed, 0 insertions, 2 deletions

diff --git a/content/code/entities-as-dependencies.md b/content/code/entities-as-dependencies.md
index b2a6a1a..95bec71 100644
--- a/content/code/entities-as-dependencies.md
+++ b/content/code/entities-as-dependencies.md
@@ -20,8 +20,6 @@ The example above is the signature (in Rust) for a hypothetical database accesso
 
 Passing keys through to the database directly like this is completely functional. As long as referential integrity is set up in the schema, the database will observe whether a `user` passed in here corresponds to a row in the `user` table or not, and will return an error if not. However, the errors that arise when someone passes an invalid identifier tend to be highly opaque and difficult to program around, and thus difficult to signal back to callers in a form more useful than a generic "data access" error. Frequently, the returned error only specifies which constraint was violated; the application programmer is then left to understand what the constraint name means (or, more regularly, to return it to the end user unmodified, who will then be _completely_ stumped).
 
-Finally, referential integrity only goes so far. If the validity of an identifier depends on state, and not just on whether a row exists or not, even the gnarly errors
-
 ## My solution
 
 Not every invalid identifier scenario results in an error. Queries to read values don't generate errors, generally; instead, they return the empty set. Converting an empty result into a not-found error is straightforwards (and is often available out of the box in data access frameworks, given how often this need arises in real software).