This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2019-05-01
Channels
- # aws (1)
- # beginners (237)
- # boot (2)
- # calva (6)
- # cider (16)
- # clara (10)
- # clj-kondo (1)
- # cljs-dev (24)
- # clojure (29)
- # clojure-brasil (2)
- # clojure-dev (20)
- # clojure-europe (1)
- # clojure-italy (56)
- # clojure-japan (1)
- # clojure-nl (16)
- # clojure-spec (12)
- # clojure-uk (12)
- # clojurescript (24)
- # clojureverse-ops (3)
- # core-async (3)
- # cursive (21)
- # datascript (5)
- # datomic (82)
- # devops (5)
- # duct (14)
- # emacs (2)
- # fulcro (2)
- # jobs (6)
- # juxt (7)
- # kaocha (6)
- # leiningen (19)
- # luminus (3)
- # nrepl (51)
- # off-topic (208)
- # other-languages (1)
- # re-frame (8)
- # reagent (9)
- # remote-jobs (6)
- # shadow-cljs (37)
- # spacemacs (6)
- # testing (12)
- # tools-deps (25)
Does anyone have a recipe for deploying a datomic pro jar to a private s3 maven that works with STS credentials e.g. granted by using aws-vault
?
so db.unique/identity means no duplicate EAV's right? e.g insert 1 color blue, 1 color blue wouldn't be allowed. as where db.unique/value. means no duplicatte AV so 1 color blue, and 2 color blue wouldn't be allowed.
where the format is Entity, attribute, value
no if its a :db.unique/identity then that VA will be used to identiy the entity
like a primary key
if you have two contradictory identities pointed at the same entity then you will get an exception
:db.unique/value
will chuck an exception if you try to assert color blue on two different entities
:db.unique/identity
will attempt to conclude that 1 and 2 are the same entity
which might chuck a contradiction exception, depending
Thanks @benha, if you dont use db.unique/value would it mean then you can refer to an entity using multiple identities?
it would, which can be extremely helpful
thanks again. I'm not sure my last statement is right, nothing in the docs makes it clear to me that once you assign db.unique/value to an entity its not the only AV you can use to refer to the entity. Just confirming that this is indeed the case 🙂 secondly, assuming the above isnt true, it would seem a good thing to use db.unique/value as its rare that you want to return two entities if your using a key, so it would be nice to enforce that. Again, thats assuming db.unique/value doesn't close that entity to one AV (primary key).
and sometimes a nasty surprise
Is it always best practice to dereference the return value of d/transact, in order to realize and handle exceptions that only occur after .get is called on the returned Future? Or is it acceptable to call d/transact without a dereference, fire-and-forget style?
This question is really "is it acceptable not to inspect for and handle errors?" Probably not?
Without deref, you will only get a timeout exception thrown from d/transact (d/transact-async will never throw)
hey all, so the following will return all values of ?e
where age is 42
[:find ?e
:where [?e :age 42]]
what if I wanted to determine if there was any ?e
in the dataset that had age set to 42? without having to check the entire unified dataset
I don't know if this is the best answer, but Datomic gives you raw access to the indexes
and this is basically a question you can ask of the VAET index via the datoms api https://docs.datomic.com/client-api/datomic.client.api.html#var-datoms
(d/datoms db {:index :vaet, :components [42 :age]})
gives you an iterable of those entities that have :age 42, which you check for emptiness
my use-case is trying to speed up a query by not having to check all ?e
s if the first ?e already passes the clause
well, not sure I'm qualified to answer that
another question - can someone confirm that or
s in datalog don't short-circuit?
e.g: both fast-clause and slow-clause will run even if fast-clause is true
(or [(fast-clause? e)]
[(slow-clause? e)])
I’ve been wondering the same thing myself. I suspect that they do not short-circuit, but I would love clarification on that.
Have you tried using rules? I’d be curious to see if they have the same behavior.
well then! 🙂
I’ve been wondering the same thing myself. I suspect that they do not short-circuit, but I would love clarification on that.
@yedi This should return only one value:
[:find ?e .
:where [?e :age 42]]
Note the period after ?e
.@jaret @marshall Have you considered exporting the DatomicLambdaRole name as an export from the Cloudformation templates for Datomic Cloud? It would make adding policies to the role easier instead of looking it up and supplying it as a parameter. Small thing, but I've wished for this more than once.
so instead of [?e :age 42]
that would bind all the results to ?e
it'd be nice to have something like [?b (some? e? :age 42)]
Regarding the or
, you should interpret or
as a union of sets. Datomic will find all entities matching the fast-clause and the slow-clause and "set union" them.
ok that makes sense and is a good way to look at it (so basically from an procedural perspective: no short circuiting)
IMO the best way is to not take the "procedural perspective" at all because it's going to cause more confusion.
ok i think i might need to do that. basically im dealing with a performance problem when using queries with multiple deeply nested rules
where rules with the same variables are showing up tons of times in the query beacuse theyre included within other rules
That said, the perf issues I encountered in clauses where most often due to bad ordering.
hm not sure if that made sense, or even if that is the source of the performance problems
but now weve limited the remaining perf problems to specific queries that leverage a ton of rules
A few heuristics I found helpful: 1. Make sure to have most specific rules first (cardinality of the matching set should be pretty low) 2. Make sure you can navigate from one rule to the next. If a rule starts doing something completely different from the rule before it, it basically means you will do a cartesian product)
and if you kinda want more clarity into the case im looking at, i have a rule that looks something like this:
(visible-instances [?person ?group] ?instance)
[?instance :instance/group ?group]
(or-join [?person ?group ?instance]
(group-admin? ?person ?group)
(person-can-see-instance? ?person ?instance))
where the rule person-can-see-instance?
also has the clause (group-admin? ?person ?group)
so if there are like 5000 instances, that group-admin rule might be getting applied 5000 times, even if its already been done once
so in visible-instances
if the user is the group-admin, i don't want it to resolve the clause (person-can-see-instance? ?person ?instance)
because i already know it can see all instances in that group
[(visible-instances [?person ?group] ?instance)
[?instance :instance/group ?group]
(group-admin? ?person ?group)]
[(visible-instances [?person ?group] ?instance)
(not (group-admin? ?person ?group))
(person-can-see-instance? ?person ?instance)]
I don't know whether it solve your overall perf issues but it should bypass your expensive clauses..
i think this is the correct version:
[(visible-instances [?person ?group] ?instance)
[?instance :instance/group ?group]
(group-admin? ?person ?group)]
[(visible-instances [?person ?group] ?instance)
[?instance :instance/group ?group]
(not (group-admin? ?person ?group))
(person-can-see-instance? ?person ?instance)]
well i guess the group-admin?
clauses should go above the ?instance clauses, so that it makes the set go to 0 before it tries to find all the instances for that group
But I'm not sure why you need two different rules for visible-instances
and person-can-see-instance
. It seems those could be one rule and only take the ?person
and the ?instance
. If you call the rule without binding ?instance
it will bind all visible instances. If you bind ?instance
it will let you know whether the person can see this specific instance.
all true, except it won't be limited to visible instances in that group, unless you added that binding prior to the rule
which you could do, but in the effort of DRY, making a rule that already encapsulate that group binding seems preferred
is retractEntity
not available in datomic cloud? I'm getting the following exception trying to remove an entity in a transaction:
ExceptionInfo Unable to resolve data function: :db.fn/retractEntity clojure.core/ex-info (core.clj:4739)