2 ms·
You're correct, I overlooked triggers. Though that may be a bridge too far for some folks, triggers are only really comfortable for folks who are deep on RDBMSe
by jacques_chester 2y ago
You're correct, I overlooked triggers. Though that may be a bridge too far for some folks, triggers are only really comfortable for folks who are deep on RDBMSes. For lots of app developers the ORM is the limit of the world.
- Mister_Snuggles 2y agoORMs could offer a unique advantage by allowing the user to describe an append-only table and generating the required triggers (or the appropriate CREATE TABLE options). They'd also be able to include helpers to make working with the table easier - like defaulting to selecting current rows only, or an easy way to specify that you want rows as-of a certain point in time. I'm not sure if any ORMs actually support this though.
- refset 2y agoI suspect there have been a great many examples and attempts at the ORM level - this one with "bi-temporal chaining" springs to mind: https://github.com/goldmansachs/reladomo https://github.com/goldmansachs/reladomo And without the ORM layer there's this extension for Postgres: https://github.com/hettie-d/pg_bitemporal https://github.com/hettie-d/pg_bitemporal
- codr7 2y agoMy "ORM" supports event sourcing, or at least easily plugging it in at the model level. https://github.com/codr7/hostr/blob/532295b40dcad6c54082e1d3c9d992321208496f/src/Hostr/Domain/Model.cs#L26 https://github.com/codr7/hostr/blob/532295b40dcad6c54082e1d3...