Fork me on GitHub
#datomic
<
2016-09-28
>
yonatanel08:09:19

@mlimotte That talk describes a solution done for an internal company application. This open ended /query endpoint shouldn't be public. There's another talk about "datomic superpowers" where they sanitize the query and add constraints (can't remember if in a database function or by appending :where clauses) according to user roles: https://www.youtube.com/watch?v=7lm3K8zVOdY

kurt-yagram11:09:07

Should lookup refs in transactions work fine? - I thought they would, but I do get :db.error/not-an-entity Unable to resolve entity: ....

[...
  {:db/id #db/id[:db.part/user]
   :some/tag "whatever"}
  {:db/id #db/id[:db.part/user]
   :ref-to-some [:some/tag "whatever"]}
 ...
]
:some/tag is a unique string (unique-value or unique-identity)

robert-stuttaford11:09:46

in map txes, you must wrap with {:db/id lr}

kurt-yagram11:09:34

so {:db/id [:some/tag "whatever"]}? What if I want to put it in a different partition?

robert-stuttaford11:09:27

:ref-to-some {:db/id [:some/tag "whatever"]}

robert-stuttaford11:09:49

at this point, it's already in a partition

kurt-yagram11:09:58

yeah, right. get it, thx.

kurt-yagram11:09:47

... or not. It doesn't seem to work: still same error.

kurt-yagram11:09:33

java.lang.IllegalArgumentException: :db.error/not-an-entity Unable to resolve entity: [:some/tag "whatever"] in datom [#db/id[:db.part/user -1] :ref-to-some [:some/tag "whatever"]]

kurt-yagram11:09:03

So, no lookup refs in transactions. Switching back to #db/id[db.part/user -1] and stuff. Too bad.

robert-stuttaford12:09:05

@kurt-yagram lookup refs can only find entities that are already in storage. you need to use temp ids to refer to temp ids

kurt-yagram12:09:09

allright, thanks!

kurt-yagram13:09:07

If I query a db, can I return a default value if a many-cardinality attribute doesn't contain any value? (something like get-else, but for many-cardinality)

marshall13:09:22

@kurt-yagram You could probably write something using missing? and ground to do so,

kurt-yagram13:09:59

aha, missing seems to be something...

kurt-yagram13:09:28

this does the trick, there may be no attrs in :some/attr :

[(missing? $ ?t :some/attr) ?no-attr]
            (or-join [?no-tag]
                     [?t :some/attr ?attrs]
                     [(when ?no-attr []) ?attrs])]
       

kurt-yagram13:09:49

or not... it's not right.

marshall13:09:25

I figured out a way to do this in the past at one point. I think it was a missing and a ground clause both inside an or

mlimotte14:09:39

@kenny thanks for the feedback. That is in-line with what I was planning. Was hoping there was already some published example, but not sure how generic vs. application-specific the result will be.

mlimotte16:09:41

@yonatanel I'm not sure that's true. The speaker at one point refers to the web service layer handle edge concerns to protect from the "Scary internet". In any case if you support authentication and authorization, and sufficiently sanitize the input, I could see doing the same thing for an internet facing application.

potetm17:09:56

Curious about the switch away from HornetQ.

potetm17:09:14

Purely performance?

marshall17:09:21

@potetm The HornetQ codebase was donated to Apache and became part of Artemis

potetm17:09:51

Ah. So basically just a HornetQ update.

leov19:09:32

hihi. can I ask maybe a stupid question, however I am new to data structures and algorithms

leov19:09:00

so I was trying to google that out, but still: is datomic um.. indexes sort of persistent data structures, right?

leov19:09:05

if so, what are in the leaves?

leov19:09:25

and what is stored in the upper level of the tree

leov19:09:49

(the guide says that datomic stores segments, not individual datoms in the tree. so this means those have to be periodically rebuilt and written anew somewhere on the disk)

bkamphaus19:09:59

@leov yes and no. It does store segments, and the indexes are periodically rewritten (see http://docs.datomic.com/capacity.html#indexing for the performance impact), but the segments themselves are immutable.

arohner19:09:20

@leov persistent datastructures means “when I ‘update’ the structure, the old one is untouched, and I have a new structure representing the change’. kind of like a git fork

bkamphaus19:09:07

if you’re interested in implementation details, etc. Rich’s Writing Datomic in Clojure talk is probably the best resource: https://www.infoq.com/presentations/Datomic (though note that some details may have changed since then of course).

kenny20:09:36

How can I get a pull pattern to be recursive at an arbitrary depth? For example:

[:db/id
 :some-value
 :nested {:foo '...}]
I want :foo to use the entire pull pattern defined above. The result I get is :nested has no data pulled:
{:db/id 1, :some-value 6, :nested #:db{:id 2}}

leov21:09:46

thank you