I've seen abstraction layers where it's impossible to add a default clause to every SELECT query for a model. Yes, it's technically the developers' fault for not understanding how and when the abstraction kicks in, but that doesn't mean it's "simple", or that these cases are avoided. Developers assume their configuration, such as appending a "deleted = false" clause, applies to every query without manually verifying each one. The majority of incidents I encounter with this bug occur specifically because of the complexity introduced with abstracted query building via ORMs and DBALs. Happens so often it's impossible to keep count. I've seen this bug over and over again at every company I've worked for. Finally, ORM abstractions often automate soft-delete in such a way that makes it exhausting for developers to validate every query. Discipline aside, it's difficult for every developer on a team to remember which tables use soft-delete, and when checking that flag is or is not necessary. Managing soft-deletes on a database table requires an attention to detail, with every single query ever touching that table, that many developers lack the discipline to handle. The query used to load one item is "WHERE id = :id" instead of the correct "WHERE id = :id AND deleted = false".
When viewing a single item (ex: message) the URL contains a unique identifier, whether an auto-increment integer, UID, etc.
When you view the list of items (ex: inbox), the database query includes a "WHERE deleted = false" to exclude rows which have been soft-deleted. That bug is extremely common, and the source is always the use of soft-deletes in the database.
0 kommentar(er)
