Open marsmay opened 9 months ago
Your understanding is partly correct. In fact, when the user needs to reuse the historical id, the user will use this logic. Therefore, a judgment can be made here. If the id is > 0, the deletion logic will be used. However, this will increase the amount of code. I will consider giving a reply.
The cache operation in the Insert method in the model generated by goctl is invalid when using the MySQL auto-increment primary key ID.
If you are using the MySQL auto-increment primary key ID.
Then use goctl to create the model code, you will get the following code for the insert method:
Because ID is generated by database increment, the ID in the key is 0. So it will trigger an operation to delete a cache with ID 0, which is meaningless and increases overhead.
I understand that this delete operation is to clear the placeholders that were built to prevent cache penetration, and this mechanism works when the ID is not set automatically but manually. However, the mechanism obviously doesn't work properly when the ID is relying on the database's auto increment, and it's not possible to remove the placeholder. This might cause other issues, for example, if the user has accessed the data with the new id, a placeholder is generated, and for a period of time, the user's request will read an error that the data does not exist.
In gorm, the Create method will assigned to the ID set as the auto-increment primary key. Even if go-zero is unable to adopt a similar design, it should solve this problem and delete the correct placeholders, to avoid hitting the wrong cache and producing the wrong results.