[dead]
Datomic is Free
411–420 of 436 posts
Re: Datomic is Free
#412[dead]
Re: Datomic is Free
#413[dead]
Re: Datomic is Free
#414[dead]
Re: Datomic is Free
#415From experience: Datomic Cloud is slow, expensive, resource intensive, designed in the baroque style of massively over-complicated CloudFormation astronautics. Hard to diagnose performance issues. Impossible to backup. Ran into one scenario where apparently we weren't quick enough to migrate to the latest version, AWS had dropped support for $runtime in Lambda, and it became impossible to upgrade the CloudFormation t…
Why backups were impossible? Couldn't you backed up the storage resources?
As far as I could tell, there was no straightforward way to point a new instance of the compute resources back at the old storage resources since they're all provisioned in one CF template.
Re: Datomic is Free
#416Earlier quoted context omitted.
Hence "the data persistence part."
This sounds like a write-back / write-through cache with extra terminology. What's the difference?
The difference is the 10,000x slower performance if you move the actual DB transaction leader for the shard to over-the-wire access.
Anything can be anywhere if we ignore latency and throughput.
Re: Datomic is Free
#417Re: Datomic is Free
#418Earlier quoted context omitted.
Yes, this hit home so hard. All objects are bespoke mini languages that add little to no value and simultaneously make it hard to remember and hard to use. Just use maps!
An object is a schema, though. A map is... Whatever you put in it.
This comment is talking specifically in the context of Clojure.
In the Clojure culture (so to speak) maps may also have a schema, as used by various schema checking tools, which are richer than runtime type checks. (Not the same as database schema)
Nit: I would not say that a JVM object is a schema, because there’s more to it. Rich is well known for saying that the idea of an object complects two things: (1) a record-like (struct) data structure with the (2) code to manipulate it.
Sometimes it’s even more complected because in some languages classes can make assumptions about state across all objects and threading.
Re: Datomic is Free
#419Earlier quoted context omitted.
Yes, this hit home so hard. All objects are bespoke mini languages that add little to no value and simultaneously make it hard to remember and hard to use. Just use maps!
Constraints always have value. Without constraints programmers are confronted with the naked complexity of mapping between the set of all possible states of N bits which is (2^N)!.
More constraints don’t necessarily have more value, though. Each constraint needs to be thought through, not just have its value assumed.
Re: Datomic is Free
#420Earlier quoted context omitted.
We implemented it in Postgres with 'created_at' and 'deleted_at' columns on everything and filtering to make sure that the object 'exists' at the time the query is concerned with. Changes in relationships between objects are modeled as join tables with a boolean indicating whether the relationship is made or broken and at what time. Our data model is not large and we had a very complete test suite already, so it was…
Yeah, it seems you could be able to substitute thoughtful schema design avoiding updates/deletes for time-travel as a feature. I wonder if anyone has made a collection of reference examples implemented this way (and in general think that a substantial compendium good examples of DB schema and thinking behind them could be worthwhile).
Ive built a couple systems that would have been datomic’s bread and butter.
Each time the company was more comfortable with mainstream dbs, so we ended going with something like you’re talking about, built on top of a db. A couple of the projects were because a mainstream dbs wouldn’t scale.
The systems definitely worked, but it was also a lot of implementation complexity on an other wise simple business prop: “store this data as facts”