This updatebypk has four parameters, of which the third parameter I feel a little chicken. Because the third parameter is a condition. Then I have only one primary key, why do I have to complete a condition? That is, through the primary key can find the only column, I have to do what conditions!
Reply content:
This updatebypk has four parameters, of which the third parameter I feel a little chicken. Because the third parameter is a condition. Then I have only one primary key, why do I have to complete a condition? That is, through the primary key can find the only column, I have to do what conditions!
No.
First of all, the last two parameters can be omitted, for simple updates, this method call is very convenient.
Second, if the update contains other restrictions, then the next two parameters will be useful. In general, use the primary key to uniquely determine a record, where the primary key is written in the first parameter position, you can highlight the primary key, the probability of error is smaller.
For example, users to update their own written articles, it is generally first by the primary key to locate the article ID, and then by the additional conditions "uid=:uid" to determine that the current user to prevent other users to submit a malicious ID to make changes. (I'm only using this scenario for the third parameter at the moment)
Like, you're going to have to update the ID 3 account to deduct 10 bucks from him.
Read the balance and then direct UPDATEBYPK
And then you're screwed, because when the trading frequency is high, there is no guarantee that after you read the balance, there is no other process to write another new balance in, even buy 2, but only once the money, and so on.
This is the time to add conditions, specifically
balance, version = readByPk pkbalance -= 10updateBypk pk, {balance:balance, version:version+1}, version=version
Prevent data confusion in concurrency scenarios with version number. It seems the jargon is called optimistic lock, you can get to know