This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2023-07-10
Channels
- # announcements (28)
- # architecture (1)
- # babashka (4)
- # beginners (55)
- # biff (4)
- # calva (11)
- # clerk (1)
- # clj-http (2)
- # clj-kondo (1)
- # clojure (46)
- # clojure-austin (1)
- # clojure-europe (32)
- # clojure-nl (1)
- # clojure-norway (17)
- # clojure-uk (4)
- # clojurescript (5)
- # cursive (6)
- # datomic (2)
- # emacs (2)
- # events (1)
- # fulcro (33)
- # hoplon (4)
- # humbleui (30)
- # hyperfiddle (50)
- # jackdaw (2)
- # jobs (13)
- # joyride (8)
- # lsp (2)
- # malli (2)
- # off-topic (6)
- # re-frame (4)
- # remote-jobs (1)
- # rum (10)
- # shadow-cljs (10)
- # xtdb (7)
When you use, play, fight, punch, shout, suffer to/from DynamoDB, you begin to understand better Datomic DB architecture. Interesting experience.
Sure! Consider this scenario: When you remove an item from DynamoDB, it can create a domino effect, potentially disrupting DynamoDB streaming. In response, you need to adjust your Lambda function to handle this situation while also preparing it exclusively for NEW_IMAGE. Datomic provides a unique feature where an item isn't fully deleted; instead, it's "marked" as deleted. While this item technically persists, it's treated like a "ghost". Special query keys enable you to access its values, though these are omitted from standard queries. This function is particularly advantageous when needing to retrieve historical data.
You can implement soft-deletion with DynamoDB as well via an attribute like deletedAt
Are we talking about soft vs hard delete? That soft delete needs to be handled properly logic-wise, otherwise you're gonna have 'ghosts' associated in your system. To solve this SQL handled it with ON UPDATE and ON DELETE configurations, where you could take different approaches based on your needs. With soft delete things can get ugly pretty quickly. For Datomic I thought the idea was to have immutable snapshots of your entire DB and move through them as needed, but I might be wrong about it as I didn't actually used it extensively.
Krisztian, you're absolutely correct that soft-deletion can be implemented in DynamoDB using a deletedAt
attribute or something similar. But this approach requires conscious planning and deliberate engineering effort.
In comparison, Datomic’s time-based, immutable data model naturally supports the idea of maintaining historical data without the need for manual implementations like the deletedAt
attribute. While it doesn't technically employ soft-deletion, it provides a similar benefit in allowing us to query the database as of a particular point in time, hence the ghost analogy.
Iulian, you've correctly noted that soft-deletion can be complex to manage and can lead to unintended ghost records if not handled properly. This is a concern that applies to many database systems, not just DynamoDB.
My original point was that the challenges and intricacies I've faced while using DynamoDB have led me to better appreciate Datomic's unique architecture. Neither is definitively superior to the other - the best choice depends on the specific use case and what trade-offs one is willing to make.