Fork me on GitHub
#datomic
<
2021-09-26
>
Tobias Sjögren11:09:57

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…

Joe Lane12:09:33

Check out the schema page. This links specifically to the valueType section. https://docs.datomic.com/cloud/schema/schema-reference.html#db-valuetype

Tobias Sjögren12:09:42

Oh, I don’t know why I couldn’t connect value and valueType.. - thanks!

Tobias Sjögren18:09:32

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?

potetm18:09:21

Entities change over time. They can have attributes added or removed or changed. Values are always just the value that they are.

potetm18:09:43

In datomic, an entity has a value at a particular time.

Tobias Sjögren19:09:28

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?

potetm19:09:52

I would say it’s probably contextual.

potetm19:09:14

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.”

potetm19:09:58

But even in that case, you could easily say, “Those are just different states. They should be distinct: green dark-green red

potetm19:09:07

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.

Tobias Sjögren19:09:16

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..

potetm19:09:30

Entities are values over time.

👍 1
Tobias Sjögren19:09:32

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..

potetm19:09:16

> it makes it non-redundant This isn’t really true. Numbers, Keywords, Strings — normal values in clojure — are interned. So they share an instance.

potetm19:09:48

So if you’re worried about memory implications of using values, you shouldn’t be.

potetm19:09:44

The real question is: Does this thing change over time? If it changes, do I want all references to change as well?

potetm19:09:15

I mean, it’s not really much different from using an id column vs a value column in SQL.

potetm19:09:24

When do you use an id column?

Tobias Sjögren19:09:10

Not thinking of memory implications..

Tobias Sjögren19:09:53

“Id column”, you mean a foreign key value pointing to another table where the “value” is located?

Tobias Sjögren19:09:20

That could be the first adapting of a relational database to the Datomic way, gradually converting..

Tobias Sjögren19:09:00

“Interned”, that’s a term that I’m not familiar with..

potetm20:09:55

Intern a fancy word for caching. (It implies no eviction mechanism and automatic, language-level resolution to the cache value.)

👍 1
potetm20:09:23

But yes, I meant an foreign key column vs a value column.

potetm20:09:37

Value column:

name | address
"me" | 123 Foo Ave.
Foreign Key Column:
name | address
"me" | 948

potetm20:09:54

The tradeoffs for one vs the other are roughly the same in datomic and SQL.

Tobias Sjögren20:09:37

Meaning the first with the value column is equally redundant in both Datomic and SQL?

Tobias Sjögren20:09:30

What I tend to think is that using a value column correlates to mutable values and the foreign key column to immutable ones..

potetm20:09:25

What’s immutable about foreign key columns?

potetm20:09:04

Is the string 123 Foo Ave mutable in SQL?

potetm20:09:40

Both value and foreign key columns can have changing values over time.

Tobias Sjögren20:09:45

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.

Tobias Sjögren20:09:21

The foreign key value can change but each value in the other table does not.

Tobias Sjögren20:09:15

That at least how I have been thinking about it while in the process of trying to learn more about things..

potetm21:09:25

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 948 to 576 when the address changes. There’s nothing totally immutable about any of this stuff!

potetm21:09:22

But when you execute a PostgreSQL query, you get a “snapshot” of the database—a point-in-time, stable, immutable value.

potetm21:09:37

All of these ideas apply equally to both datomic and SQL.

Tobias Sjögren21:09:38

Certainly any value can change - I just used it as a model to better understand “immutability”.

potetm21:09:02

SQL actually does a really good job of exemplifying many of the ideas behind Datomic.

potetm21:09:26

The major innovations of datomic really build on top of SQL, they do not replace them.

potetm21:09:44

So I would suggest solidifying some of these ideas just thinking about SQL.

potetm21:09:20

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

potetm21:09:45

But, again, the things you’re talking about are definitely things you can reason about just with SQL.

Tobias Sjögren19:09:13

I am in the process of watching them!

Tobias Sjögren19:09:09

So far, my feeling is that it, the term “value”, lacks a proper definition..

Joe Lane19:09:34

Fwiw, Datomic is a relational database.

Tobias Sjögren20:09:17

Care to elaborate?

Tobias Sjögren20:09:36

Datoms being located in a single “relation” making atomic a relational database?

Tobias Sjögren20:09:54

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..

Joe Lane20:09:54

Well you can safely assume that meaning when you are working with Datomic or in Clojure.

Tobias Sjögren20:09:16

To the degree it is a Clojure/Datomic specific definition, it would need further explanation - at least for me..

Joe Lane20:09:55

Let me know if the three videos don't answer your questions. Bonus video https://youtu.be/ScEPu1cs4l0

👍 1
Linus Ericsson20:09:33

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 A. The 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 E. 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 E. One confusing thing is that :db.type/ref also points out an entity with has an attribute :db/ident. The documentation of datomic differens from most other softwares because it is very terse. You have to read it carefully.

👍 1
Tobias Sjögren20:09:04

Concerning the documentation, the fact that it is split up into On-Prem and Cloud and redundant over the two is not optimal..

Linus Ericsson20:09:21

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.

Linus Ericsson20:09:50

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/)

Tobias Sjögren20:09:00

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..

Joe Lane20:09:51

Have you worked with Clojure before @tobejazz ?

Tobias Sjögren20:09:51

My tool at the moment is FileMaker.

Joe Lane20:09:29

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”.

Tobias Sjögren21:09:51

Oh, so Clojure and Datomic are complected 😉 I will certainly check the videos out..

3