Hacker News Reader

Comment by louprado | Hacker News Reader

Any advice when saving new DB records ? We usually return the new ID in our return result, but it is not available when using async/await. Is it possible to send a second result with the ID and how does one create a listener for the second result in Javascript ?

Edit: Because we use async HTTP requests, we aren't blocking the UI. On further thought, the problem I described is not a good use case for async/await.

View on HN

It can be a good use case, to increase the number of concurrent users you can serve. See my comment elsewhere in this thread.

You should still be able to output an ID when using async/await. It just means that the calling thread can do something else while it waits for the DB to get back to it. Execution will resume in the same place.

As mentioned elsewhere in this thread, for a distributed system you can use GUIDs to remove a immediate dependency on the DB. You can adopt eventual consistency and merge later, but this adds lots of complexity. If you do go down this route, add the GUIDs as an additional key and stick with something sequential for PKs, to avoid clustering issues.

Define your method like this:

  public Task<MyResult> ExecuteDatabaseQueryAsync()
  {
    return yourDbObject.SomeMethodAsync();
  }
  ...
  MyResult result = await ExecuteDatabaseQueryAsync();

The actual code in ExecuteDatabaseQueryAsync will differ depending on what data access technology you use. Often, the method is called something like ExecuteScalarAsync.

In addition to what nathanaldensr suggested I would add that you should try to architect your application in a way that you don't have to wait for the DB to give your ID back.

Using GUID as ID is an option, but there are plenty of other methodologies to generate the ID in the client and not be held hostage by the DB to get your IDs.

While I agree that using GUIDs here would work to solve the issue, I wouldn't blindly use GUIDs without looking at the performance impact. The use of GUIDs as the primary key in something like SQL Server for large tables could cause read performance issues down the line.

I was thinking of mentioning this, but I wanted to avoid given design advice for systems I haven't seen. In virtually all of my own projects, I use business-logic-generated GUIDs for IDs. There are a whole bunch of easily-Googleable benefits for GUIDs over database-generated IDs.

async/await is not just to avoid blocking UI. It's to avoid blocking any thread, so that it can be reused for a different task while yours is awaiting completion of some dependency.

It's not entirely clear what your problem is from that description. Why is the new ID not available when using async/await? If your "add a record" operation produces an ID in sync version, then the async version of it should not be considered logically completed until said ID is returned. Are you using some library that works differently?

Reply on news.ycombinator.com