In an application that doesn't use an ORM, is it good practice to check whether an object exists before attempting to update/delete it?

For example:

 @Route(method="DELETE", path="/posts/\d+")
 public function deletePost(id: number) {
      let post = model.getPost(id) // this method does a SQL SELECT
      if (post == null)
          return new NotFoundResponse()

      try {
          model.deletePost(id) // this method does a SQL DELETE
          return new OkResponse()
      } catch (e: DatabaseError) {
          // handle error
          return new ServerError()

In essence I'd be doing a SELECT query prior to the DELETE query (and same with updates). Is this recommended?

What about child object/collections? Does the same logic apply?

For example if I were to issue a UPDATE /posts/123/comments/456, should I check the existence of post 123 and comment 456 before updating?

  • Just wondering, are you, or team, maintaining the API used to do the query against the DB? If so, why couldn't you have the underlying query act like a "Try Parse" concept, where the operation would give back something like an object with a success flag and collection of result lines? Mar 4, 2019 at 2:28
  • Yes, it is the same team. Would you care to elaborate on what you mean by "Try Parse"? Does this concept only work for mutations or reading as well? Mar 4, 2019 at 8:11
  • I was meaning that, for the method that does the SQL Delete, modify the query to have conditionals, like setting @IsValidPostId true based on finding the row. Consolidating the check/action to one query. Then for a Response, let the query return tabled set of data such as rows of successful/unsuccessful flags and result message(s). For this delete case, it would be something like "DbResponse = model.TryDeletePost(id);", where DbResponse represents the results of trying to perform the delete. I am kinda wondering if i went in a different direction than you were looking for. Mar 5, 2019 at 1:54

1 Answer 1


I'm going to go with "no" because not only does that mean more round-trips to the DB, but also you can't guarantee that another call to the same API isn't happening at the same time, so you can't be certain that the delete call isn't still being made against an already deleted record.

Instead, just try and do the delete and handle appropriately if the DB is one that throws an error for deleting a non-existent item.

Especially if you're doing REST semantics, try and think of it less like being sure an operation is performed as requested and think of it more like ensuring the intended state is achieved.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.