4 ms·
I don't understand what the 'version' column is for. You can get the sequence by just looking at the 'version_on' attribute. Deletes are already restricted on t
by mapleoin 11y ago
I don't understand what the 'version' column is for. You can get the sequence by just looking at the 'version_on' attribute. Deletes are already restricted on that table and it wouldn't solve concurrency issues since it's generated by the trigger.
- dwrowe 11y agoUnless you wanted to have a count of versions, without having to execute a second query. Or have some future means of rollback - 'active' versioning system?
- smerchek 11y agoConcurrency issues can be solved by restricting the UPDATE to the version passed in by the application. If I think I'm updating version 2 of an entity, then only update that version, otherwise throw an error. I've updated the post to address this scenario.
- mapleoin 11y agoI don't see the update in the post. If you pass the version in an UPDATE statement it will get overridden by the trigger. NEW.version := OLD.version + 1;
- smerchek 11y agoThe version is part of the WHERE clause in the UPDATE statement. Therefore, it is only possible to update the version of the entity that you were updating. If the entity is updated before your statement, it would not succeed in updating the row. Is there a different concurrency issue I'm not seeing caused by updating the version in the trigger?
- mapleoin 11y agoYes, you're right. I didn't notice the WHERE in the UPDATE statement. That makes a lot more sense now, thanks! You still have the issue of someone setting the version explicitly in an update statement without a WHERE clause which checks for the current version. But I guess as long as you enforce not doing that it's fine.