41–50 of 93 posts
I recall Datomic making a bit of a splash on HN when it was announced 6+ months ago, but basically crickets since then. Anybody build something cool that took advantage of Datomic's unique design?
I don't think datomic (or it's kin) will have that huge of an influence until years from now.
I'm always puzzled when the Datomic folks speak of reads not being covered under a transaction. This is dangerous. Here's the scenario, that in a conventional update-oriented store, is termed as a "lost update". "A" reads object.v1, "B" reads the same version, "B" adds a fact to the object making it v2, then "A" comes along and writes obj.v3 based on its own _stale_ knowledge of the object. In effect, it has clobbere…
I recall Datomic making a bit of a splash on HN when it was announced 6+ months ago, but basically crickets since then. Anybody build something cool that took advantage of Datomic's unique design?
People tend to be more conservative about data than they are about the other parts of their stack -- probably for a good reason. I don't think datomic (or it's kin) will have that huge of an influence until years from now.
How would you idiomatically fix invalid data in Datomic? for example, if you needed to update a badly entered value in a record, but keep the record's timestamp the same so as not to screw up historical queries?
You wouldn't. You can't change history either. You would insert a compensating transaction and the data would be fixed from that time forward when you inserted the compensating transaction.
Anyone understands how this system would deal with CAP theorem, in the case of a regular "add 100$ then remove 50$ to the bank account, in that order and in one go" type of transaction ? The transactor is supposed to "send" novelty to peers, so that they update their live index. That's one point where i would see trouble (suppose it lags, one "add" request goes to one peer, the "read" goes to the second, you don't fi…
Earlier quoted context omitted.
People tend to be more conservative about data than they are about the other parts of their stack -- probably for a good reason. I don't think datomic (or it's kin) will have that huge of an influence until years from now.
I think Datomic is potentially disruptive and represents some great thinking on the part of an individual. Whether it will be disruptive will hinge on how well that thinking has subsumed the years of industry experience and practicalities, not to forget the conservative approach to data. I'd be interested to see how it pans out.
Anyone understands how this system would deal with CAP theorem, in the case of a regular "add 100$ then remove 50$ to the bank account, in that order and in one go" type of transaction ? The transactor is supposed to "send" novelty to peers, so that they update their live index. That's one point where i would see trouble (suppose it lags, one "add" request goes to one peer, the "read" goes to the second, you don't fi…
I'm always puzzled when the Datomic folks speak of reads not being covered under a transaction. This is dangerous. Here's the scenario, that in a conventional update-oriented store, is termed as a "lost update". "A" reads object.v1, "B" reads the same version, "B" adds a fact to the object making it v2, then "A" comes along and writes obj.v3 based on its own _stale_ knowledge of the object. In effect, it has clobbere…
Earlier quoted context omitted.
I did too until I realized I wasn't ready for so much lispiness, too abstract for me right now.
"too abstract" is not a phrase I'd think to associate with a lisp. It's all just data. If anything I'd expect people to say there's too little abstraction.