Fork me on GitHub
#datomic
<
2018-04-19
>
caleb.macdonaldblack10:04:11

Anyone know any easy way to count how many datoms datomic has stored? I’d like to see close I am to the recommended 10bil limit

robert-stuttaford10:04:22

(count (seq (d/datoms db :eavt))) 🙂

val_waeselynck11:04:14

You may want to do that on a history db

stuarthalloway11:04:25

@robert-stuttaford walking that seq will pull all X billion datoms through the peer, pounding storage and blasting whatever was cached

stuarthalloway11:04:43

note to self: add the db-stats API to peer

robert-stuttaford12:04:49

db-stats on peer would be rad, yes please

caleb.macdonaldblack12:04:44

@stuarthalloway Ahh thank you. I’m currently just messing around in a non-production side project so no harm done. Good to know for future though

val_waeselynck12:04:10

@marshall About Excision, I found the following assertion in the On Prem docs (https://docs.datomic.com/on-prem/excision.html#limitations): > Excision of :db/fulltext attributes is not supported. Is this still the case? It does seem to work on my dev connection on my local machine. I excised a :db/fulltext attribute, called syncExcise, and obtained different search results before and after the excision. I'm on Datomic 0.9.5407

marshall12:04:51

@robert-stuttaford @caleb.macdonaldblack You can also look at the :Datoms metric in the logs (or metrics), reported on every indexing job - that will tell you how many total datoms in your DB

caleb.macdonaldblack13:04:09

Ive never actually read those. I didn't know that you could see the datom count there. Thanks!

stuarthalloway13:04:42

@val_waeselynck excise completely ignores the fulltext index. You will get different results because of changes in the other indexes, but the fulltext index is not excised.

val_waeselynck13:04:35

@stuarthalloway allright, so assuming I have some data in a :db/fulltext attribute that I need to erase for legal reasons, is there a way to use excision (or something else) to that end?

stuarthalloway17:04:14

excision will not erase the fulltext index, and I would recommend against using fulltext on things that might need excision

val_waeselynck19:04:04

Yeah, I screwed up making everything fulltext by default. Will have to rewrite the db manually. Hell, that will probably make for another interesting blog post.

souenzzo19:04:54

There is ANY chance to @(d/transact conn tx-data) install data on DB and throw a exception?

souenzzo19:04:33

it's saver use (d/transact-async conn tx-data)?

marshall20:04:56

@souenzzo if a transaction throws an exception the entire transaction is aborted

marshall20:04:12

the dereferencing itself could time out or hit some issue

marshall20:04:36

using either sync or async — so if you see an error you should query to determine if the transaction completed or not

brunobraga23:04:22

hey guys, I have a dummy questions. I read everywhere that datomic and immutability provides a way to get read of side-effects and that concurrent programming becomes much easier...but that just does not get into my head. If I have a database, and multiple client are reading and writing into it, how does a complete copy of the data (which is immutability) solves the problem of one of these clients simply have a copy that is not up to date?

val_waeselynck04:04:45

Immutability allows perception to be consistent and free of coordination; it doesn't prevent clients from perceiving a past view of the world when reading, which is a limitation that all databases have and is due to the physical way in which information propagates. When writing, Datomic prevents race conditions by running transactions serially (on an up to date view of the db); immutability doesn't especially help here, except for the performance aspect of writes not being impeded by reads.