This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # announcements (2)
- # asami (2)
- # aws (34)
- # babashka (6)
- # beginners (9)
- # calva (76)
- # chlorine-clover (10)
- # circleci (5)
- # clj-kondo (2)
- # clojure (40)
- # clojure-australia (3)
- # clojure-europe (15)
- # clojurescript (39)
- # conjure (1)
- # core-async (4)
- # cursive (4)
- # datahike (1)
- # datomic (69)
- # figwheel-main (1)
- # graalvm (16)
- # honeysql (9)
- # hyperfiddle (2)
- # jobs-discuss (2)
- # lsp (36)
- # luminus (1)
- # malli (11)
- # off-topic (13)
- # pathom (1)
- # portal (1)
- # portkey (3)
- # reitit (25)
- # reveal (1)
- # rewrite-clj (5)
- # spacemacs (2)
- # sql (4)
- # vrac (90)
Newbie question: What “kind” of content can the Datom value have? Beyond a simple string like “pizza”, can the value be an entity id? In the product docs there’s also “:green” as the value, what is that? Sorry, I’m not even sure what the colon means…
Check out the schema page. This links specifically to the valueType section. https://docs.datomic.com/cloud/schema/schema-reference.html#db-valuetype
Thinking about the idea of immutable values makes me think that they are in fact identical to entities. If not, what is the fundamental difference?
Entities change over time. They can have attributes added or removed or changed. Values are always just the value that they are.
If and when a value needs a have a value attached to it (“green” needs to be either “light” or “dark” e.g.), it should become an entity - so if you are unsure of whether it is a pure value or if it is to become an entity, you might just as well make it an entity right away - would you agree to that?
Like, if you have a process where a light has a base color and a hue with different meanings, then yes. For example, if you had a light where light green meant “good,” dark green meant, “good, but borderline,” and red meant, “bad.”
But even in that case, you could easily say, “Those are just different states. They should be distinct:
More to your question, rather than your example, I think you’re on the right track. Any time you need multiple attributes to constitute a value, you should consider using an entity.
You can also consider a tuple: https://blog.datomic.com/2019/06/tuples-and-database-predicates.html
Thanks. I need to gain a better understanding of what a value actually is in comparison to an entity, an specifically what it means for an value to be immutable the way Hickey talks about it. Coming from a relational database system I’m used to change this field value to that new value. What it would mean to go immutable is, I guess, to have the values stable and just change the pointer from one value to another value. It might do good for my understanding of immutable values to have the relational model as the starting-point to convert from so to speak..
What would be the benefit of defining “green” as a value compared to it as an entity? The obvious reason, as far as I understand, of defining “green” as an entity is that it makes it non-redundant - if green is a value, then the “green” instances (connected to different entities) are copies of each other without any connection..
> it makes it non-redundant This isn’t really true. Numbers, Keywords, Strings — normal values in clojure — are interned. So they share an instance.
The real question is: Does this thing change over time? If it changes, do I want all references to change as well?
I mean, it’s not really much different from using an id column vs a value column in SQL.
“Id column”, you mean a foreign key value pointing to another table where the “value” is located?
That could be the first adapting of a relational database to the Datomic way, gradually converting..
Intern a fancy word for caching. (It implies no eviction mechanism and automatic, language-level resolution to the cache value.)
Foreign Key Column:
name | address "me" | 123 Foo Ave.
name | address "me" | 948
Meaning the first with the value column is equally redundant in both Datomic and SQL?
What I tend to think is that using a value column correlates to mutable values and the foreign key column to immutable ones..
Given that the value in the other table (that the foreign key is connected to) is stable/immutable, then the foreign key column option of yours above represents the immutability.
That at least how I have been thinking about it while in the process of trying to learn more about things..
1. In SQL, the values in the foreign table can change.
2. The value in the local table can change too! e.g. In the above example, you can change
576 when the address changes.
There’s nothing totally immutable about any of this stuff!
But when you execute a PostgreSQL query, you get a “snapshot” of the database—a point-in-time, stable, immutable value.
Certainly any value can change - I just used it as a model to better understand “immutability”.
The major innovations of datomic really build on top of SQL, they do not replace them.
Just to make it easier for you, some of the major innovations that SQL doesn’t have are: 1. History by default 2. Universally serialized transactions 3. Automatic indexing of every entity/attribute/value 4. Available transaction log with full history 5. A data-first query language 6. Automatic caching
But, again, the things you’re talking about are definitely things you can reason about just with SQL.
https://docs.datomic.com/cloud/whatis/data-model.html#universal All datoms are in the same relation in datomic
Datoms being located in a single “relation” making atomic a relational database?
Back to the value thing. A value being defined as “Something that does not change” seem to be a Hickey definition - but I might be wrong about that..
Well you can safely assume that meaning when you are working with Datomic or in Clojure.
To the degree it is a Clojure/Datomic specific definition, it would need further explanation - at least for me..
Let me know if the three videos don't answer your questions. Bonus video https://youtu.be/ScEPu1cs4l0
In the datomic data model you have datoms, which are of the form
[E A V Tx (added?)] where
E is an entity id. It is a long (but could be thought of as a pointer into a datastructure containing all the database data).
A is also a long and points to a a certain entity that describes the attribute. The type of
V is always determined by the
valueType of the attribute entity pointed out in
Tx (transaction) is also a long. and points to a transaction entity.
Added? is a boolean describing if the datom was added or retracted. In the ordinary database view it always true (since retracted datoms are not visible anymore).
An entity in datomic is all datoms who share the same
A reference (that's the relational part) must have a
Apointing out a schema entity whose valuetype is
:db.type/ref and has a
V pointing out an
One confusing thing is that
:db.type/ref also points out an entity with has an attribute
The documentation of datomic differens from most other softwares because it is very terse. You have to read it carefully.
Concerning the documentation, the fact that it is split up into On-Prem and Cloud and redundant over the two is not optimal..
Yeah, that is confusing sometimes. Are you using datomic On-Prem or Datomic Cloud? There are difference between these products so you should look into the right manual.
The various datatypes and literal forms in clojure are described here: https://clojure.org/reference/reader#_reader_forms (it's also very terse. A introduction could be https://www.braveclojure.com/)
I got my eyes on Datomic about a week ago, and I’m all in to learn about it to gradually going away from the relational database that I’m using at the moment - at least incorporating new ideas to begin with.. So no, I ’m not a user of any of them yet..
The philosophy of Clojure and Datomic are fairly intertwined. Learning the basics of Clojure may greatly aid you in understanding Datomic. The last talk I linked to you (are we there yet) is where the “Epochal Time Model” is introduced (if I remember correctly). It harkens back to the philosopher Alfred North Whitehead and his ideas found in his writings on “Process and Reality”.