datomic 2022-10-24 | Slack Archive

Good morning! I have the following code:

(defn db-fixture
  [f]
  (dl/divert-system {:system "yardwerkz-dev" :storage-dir :mem})
  (f)
  (dl/release-db {:system      "yardwerkz-dev"
                  :db-name     datomic/database-name
                  :storage-dir :mem}))

(use-fixtures :each db-fixture)

It seems that in my unit tests, the entities that I put into the database (which should be diverted) are persisted to the cloud. When I run my tests two times in a row, I get a uniqueness constraint. I am sure I have made a mistake. Can anyone help me? Thanks.

pppaul15:10:25

i don't use cloud, but on prem the db uri has to look something like "datomic:<mem://memorydb>" for in memory db to work

onetom19:10:42

@UGNMGFJG3 why don't u use dev-local for testing purposes? https://docs.datomic.com/cloud/dev-local.html

IM14:10:54

Hi all, Are queries (`d/q`) on d/history db optimized in some way? Or do they cause seeking through all assertions/retractions?

pppaul14:10:18

pretty sure there is order on tx id and tx date

robert-stuttaford15:10:32

it still uses the same indexes in their sort orders eavt aevt avet vaet - but they contain more datoms because all true and all false instead of latest-only-true datoms are present

👍 2

robert-stuttaford15:10:06

given that t is in this ordering, that means oldest stuff is fastest to work with cos its at the top of the index when you look

robert-stuttaford15:10:01

this will only feel slow if you're working with large numbers of entities, but if e.g. looking at the history of a single entity, it should feel not substantially slower

👍 1

robert-stuttaford15:10:19

(sorry end of day brain, not speaking too clearly 😅 )

IM15:10:27

Right, so considering eavt index, something like this should be pretty fast at all times? (as e and a are given)

...
:in $ ?eid ?e-attr ?asserted-value
:where
[?eid ?e-attr ?asserted-value ?tx true]
...

pppaul15:10:51

that's something you need to profile. fast is subjective

pppaul15:10:29

there are a lot of scenarios where a full index scan is considered fast enough

pppaul15:10:09

that query is going to cut the DB down a lot, but if your DB is being abused and you have 1 billion records that satisfy it, then you could end up in pain town too.

pppaul15:10:18

i think there may be other ways to find all the transactions for an eid, though.

IM15:10:49

It's not looking for all transaction for an entity, it's looking for a transaction on a specified entity and attribute with specific assertion value.

IM15:10:32

Considering messages above, it sounds like it should be pretty efficient

pppaul15:10:05

it should be pretty fast, but you should also be profiling as well. cus a slow query is ok in some places, and a fast query isn't fast enough in others. you can also seed your DB with a ton of data and try your query on it, that'll sort of give you an estimate of how it'll perform in the scenarios you test. i do this when trying to figure out how long my brute force solutions will work for.

☝️ 1

robert-stuttaford19:10:01

if you have e a and v and you want all the t then history will be fast enough imho 🙂

2022-10-24

Channels