Return to Answer

Commonmark migration

edited Jun 16, 2020 at 10:01

Problem: It's possible for a user to see an empty or incomplete list.

Problem: It's possible for the user to see duplicate entries.

I suspect that you are not using Transactions when making these updates.

With Transactions, users will only see the end result of your [transactional] manipulations. They will never see the intermediate state where duplicates are present (or no rows at all).

Begin transaction Insert/ Update/ Delete, as required Commit

Transactional changes should be quick because many DBMSs will block access to the rows or tables being worked on until the Commit (or Rollback) is executed.

Problem: It's possible for a user to see an empty or incomplete list.

Problem: It's possible for the user to see duplicate entries.

I suspect that you are not using Transactions when making these updates.

With Transactions, users will only see the end result of your [transactional] manipulations. They will never see the intermediate state where duplicates are present (or no rows at all).

Begin transaction Insert/ Update/ Delete, as required Commit

Transactional changes should be quick because many DBMSs will block access to the rows or tables being worked on until the Commit (or Rollback) is executed.

Problem: It's possible for a user to see an empty or incomplete list.

Problem: It's possible for the user to see duplicate entries.

I suspect that you are not using Transactions when making these updates.

With Transactions, users will only see the end result of your [transactional] manipulations. They will never see the intermediate state where duplicates are present (or no rows at all).

Begin transaction Insert/ Update/ Delete, as required Commit

Transactional changes should be quick because many DBMSs will block access to the rows or tables being worked on until the Commit (or Rollback) is executed.

Source Link

answered Jun 28, 2016 at 11:17

Phill W.

13.1k
4
27
42

Problem: It's possible for a user to see an empty or incomplete list.

Problem: It's possible for the user to see duplicate entries.

I suspect that you are not using Transactions when making these updates.

With Transactions, users will only see the end result of your [transactional] manipulations. They will never see the intermediate state where duplicates are present (or no rows at all).

Begin transaction Insert/ Update/ Delete, as required Commit

Transactional changes should be quick because many DBMSs will block access to the rows or tables being worked on until the Commit (or Rollback) is executed.