Fork me on GitHub
#datomic
<
2018-01-08
>
Vincent Cantin11:01:45

I found a typo on the web site (http://docs.datomic.com/transactions.html) "three ways to sepcify an entity id" -> specify

jaret15:01:05

I’ll fix it right now. Thanks for the catch!

Vincent Cantin09:01:59

It is still there.

hansw16:01:57

there's a couple more there

hansw16:01:06

Each list a transaction contains represents either

hansw16:01:47

and, similarly Each map a transaction contains is equivalent to @jaret

jaret16:01:55

Thanks! I’ll fix those as well.

jaret16:01:52

@U8L9BNAJE The wording seems correct to me. I did note that we had a semi colon where we needed a comma though. Here is the original text: >“Each list a transaction contains represents either the addition or retraction of a specific fact about an entity, attribute, and value; or the invocation of a data function, as shown below.”

hansw17:01:53

@jaret on 3rd read, yes, you are correct. Maybe it's the language barrier but my mind was hung-up on reading it like "Each list [in] a transaction" but now I understand it refers to what is above

hansw17:01:48

Maybe 'Each list that is contained by a transaction represents...' is better?

jaret18:01:31

It’s definitely a mouthful. I’ll confirm with the team to see if a rewording, like the one you suggested would work.

Vincent Cantin16:01:30

I am a beginner with the Clojure eco-system, and after fast-reading Datomic's documentation I still have difficulties understanding its position compared to another db-bound framework/data-flow which I am familiar with : Meteor. Here are my questions: 1. Suppose that I want to dev a web-app with reactive data update from the db to the ui, similar to what can be done with Meteor, is Datomic a valid candidate for a replacement? Would something be missing in the reactivity chain between the client and the server-side peer? 2. How/where is handled what part of the data each client is/is-not supposed to see?

Vincent Cantin16:01:39

Now that I think about it, I did not see anywhere a mention about reactivity or pub/sub. Maybe that's not what Datomic was designed for. Sorry if I misunderstood.

timgilbert16:01:10

Datomic has the capabilities to do this, but isn't particularly specialized for it. Having immutable data is a big enabler of that kind of thing though. If you were to write something like this, you'd probably use the transaction report queue. There's a project aiming to demonstrate this here (I haven't looked at it closely): https://github.com/waf/push-demo

timgilbert16:01:52

You'd still need a web server in there to do the tx-report-queue to websockets transmission, and to do security filtering, etc. That part of the code isn't built in to datomic and you have a lot of options

timgilbert16:01:16

There is a project called datsys which aims to do a lot of this type of thing, replicating a datomic database into the client and then hooking that up to react. It still seems like early days though. https://github.com/metasoarous/datsys

hansw16:01:30

While we're on the subject of txdata... What could be wrong here: I have this tx: [:db/retract 17592186045418 :myns/myattr #inst "1999-06-23T22:00:00.000-00:00"] but I get: :db.error/invalid-lookup-ref Invalid list form: [:db/retract 17592186045418 :myns/myattr #inst "1999-06-23T22:00:00.000-00:00"]

favila16:01:26

Is that the entire tx? no outer containing list?

hansw16:01:06

It's not the entire tx

favila16:01:07

[map-or-tx-fn, map-or-tx-fn, ...] is the format

hansw16:01:43

yeah, a 'list of lists' as it says in the datomic doc

favila16:01:22

error indicates it thinks your assertion is being used as a lookup ref

favila16:01:51

so it's either a value in a map or nested too deep in a list

favila16:01:07

maybe you map somewhere where you should mapcat?

hansw16:01:35

must every retraction be processed in a seperate call to transact?

hansw16:01:59

ok so i'm getting the collection-dimensions wrong somewhere...

favila16:01:22

no, retractions do not need to be alone

hansw16:01:28

my full tx combines updates and retractions. That is not invalid, correct? (as long as i provide the correct list)

favila16:01:36

there are no transaction batching restrctions except you can't do conflicting things

favila16:01:52

but that's not the case here

favila16:01:56

this is clearly a syntax error

favila16:01:14

if you pretty-print your transaction (entry per line) it may be easier to see

hansw16:01:22

thnx so far

hansw18:01:16

fixed it, and you were, of course, correct 🙂

hansw16:01:03

Could this be related to the :db/txInstant of my schema?

caleb.macdonaldblack23:01:06

How are other people managing schema and data changes in their projects? Kinda like database migrations in a relational database.

csm23:01:05

We wrote a tool that scans the current schema from the database, compares that to our master schema definition (just a bunch of edn), creates a diff between the two, and applies the diff. Overall it wasn’t hard to write.

timgilbert04:01:30

We generally use https://github.com/rkneufeld/conformity which is simple and just makes sure you don’t apply the same block of transactions twice in a give database

timgilbert04:01:24

We’ve been looking into https://github.com/luchiniatwork/migrana too, which is somewhat ActiveRecord inspired, apparently