Hacker News Reader

Comment by mapleoin | Hacker News Reader

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.

View on HN

Concurrency 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.

I 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;

The 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?

Yes, 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.

Unless 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?

Reply on news.ycombinator.com