3 ms·

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 sen

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.

int_19h 10y ago
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?
nathanaldensr 10y ago
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.
tucaz 10y ago
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.
- jordz 10y ago
  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.
- nathanaldensr 10y ago
  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.
jsingleton 10y ago
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.

int_19h 10y ago

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?

nathanaldensr 10y ago

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.

tucaz 10y ago

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.

jordz 10y ago
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.
nathanaldensr 10y ago
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.

jsingleton 10y ago

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.