this post was submitted on 06 Nov 2023
1314 points (98.7% liked)

Programmer Humor

32495 readers
696 users here now

Post funny things about programming here! (Or just rant about your favourite programming language.)

Rules:

founded 5 years ago
MODERATORS
 
you are viewing a single comment's thread
view the rest of the comments
[–] Rhinoshock@lemmy.world 29 points 1 year ago (3 children)

In T-SQL:

BEGIN TRANSACTION

{query to update/delete records}

(If the query returned the expected amount of affected rows)

COMMIT TRANSACTION

(If the query did not return the expected amount of affected rows)

ROLLBACK TRANSACTION

Note: I’ve been told before that this will lock the affected table(s) until the changes made are committed or rolled back, but after looking it up it looks like it depends on a lot of minor details. Just be careful if you use it in production.

[–] jaybone@lemmy.world 7 points 1 year ago (1 children)

Lol why did I have to scroll so far to see ROLLBACK

[–] rwhitisissle@lemmy.ml 3 points 1 year ago

Because this is c/programmerhumor and the OP hasn't covered ROLLBACK yet in his sophomore DB class.

[–] tweeks@feddit.nl 4 points 1 year ago

If for example a client application is (accidentally) firing doubled requests to your API, you might get deadlocks in this case. Which is not bad per se, as you don't want to conform to that behaviour. But it might also happen if you have two client applications with updates to the same resource (patching different fields for example), in that case you're blocking one party so a retry mechanism in the client or server side might be a solution.

Just something we noticed a while ago when using transactions.

[–] joemo@lemmy.sdf.org 3 points 1 year ago

Transactions are the safe way of doing it.

You can also return * to see the changes, or add specific fields.

Like for example:

Begin; Update users Set first_name='John' Where first_name='john' Returning *;

Then your Rollback; Or Commit;

So you'd see all rows you just updated. You can get fancy and do a self join and see the original and updated data if you want. I like to run an identifying query first, so I know hey I should see 87 rows updated or whatever.

Haven't had any issues with table locks with this, but we use Postgres. YMMV.