For those interested, my question has been answered on http://ask.datomic.com:

> Memcache-java-asg is a fork of com.aws/elasticache-java-cluster-client which is a fork of spymemcached. You should feel free to exclude our dependency here as needed. You would only use this jar if you were using elasticache and auto node discovery

https://ask.datomic.com/index.php/966/multiple-cves-are-reported-on-datomic-peer-1-0-7075?show=979#a979

Hey @UGNFXV1FA I wanted to make sure you saw my last update. After further investigation we believe these are all false positives: https://ask.datomic.com/index.php/966/multiple-cves-are-reported-on-datomic-peer-1-0-7075

I hadn’t seen that, thanks for the heads up! These false positives can be annoying at times but overall I guess we’re better off using nvd-clojure!

I mean the good outcome here is we weren’t actually checking that jar as we thought. Now we are.

Oh by the way: only excluding that jar in the datomic dependency gave me runtime errors about "class not found", so I ended up just suppressing the CVEs.

Could you provide some code as example?

Let’s say my schema has nodes, users and modifications:

(def schema [{:db/ident :node/id
              :db/valueType :db.type/string
              :db/cardinality :db.cardinality/one
              :db/unique :db.unique/identity}

             {:db/ident :node/val
              :db/valueType :db.type/string
              :db/cardinality :db.cardinality/one
              :db/unique :db.unique/identity}

             {:db/ident :node/children
              :db/valueType :db.type/ref
              :db/cardinality :db.cardinality/many}

             {:db/ident :user/id
              :db/valueType :db.type/string
              :db/cardinality :db.cardinality/one
              :db/unique :db.unique/identity}

             {:db/ident :user/name
              :db/valueType :db.type/string
              :db/cardinality :db.cardinality/one}

             {:db/ident :modification/id
              :db/valueType :db.type/string
              :db/cardinality :db.cardinality/one
              :db/unique :db.unique/identity}
             
             {:db/ident :modification/user-id
              :db/valueType :db.type/ref
              :db/cardinality :db.cardinality/one}])

(d/transact (get-connection) {:tx-data [{:node/id "1"
                                         :node/val "node 1"
                                         :node/children [{:node/id "2"
                                                          :node/val "node 2"}]}]})

(d/transact (get-connection) {:tx-data [{:user/id "1"
                                         :user/name "name"}]})

I think the main question is how to link a transaction to my own data, what is the best practice?

@U02U1T66REZ I have added another entity in my schema and inserted it in the same transaction that was made to the tree, which gave me the tx link between them

Datomic does not enforce this. For maintaining valid options, you could use convention/namespacing of enum entities, or perhaps add some metadata on the schema entities. For example, having an enum entity reference its schema attribute. An example of namespacing is in attribute_groups.clj in day-of-datomic. For constraining in transactions, look into Attribute Predicates and Entity Specs in the Schema docs. See e.g. entity_specs.clj in day-of-datomic. These could then use the mechanisms above to know the valid options and then reject tx for invalid options.

+1 for entity and attribute specs for this sort of constraint. It's opt-in, but better than nothing.

Something like:

(d/q '[:find (pull ?e [:category/name {:category/items [:item/name]}])
          :where [?e :category/name]]
        db)

(d/q '[:find [?category-name (sample 10 ?item-name)]
 :where [?e :category/name ?category-name]
        [?e :category/items ?i]
        [?i :item/name ?item-name]]
        db)

Nothing easy comes to mind. Pull is really designed to work after the query has identified the entities and once you start pulling, the aggregate functions (like sample) are out of scope. There is an ability to limit the number of referenced entities that are returned -but to the best of my knowledge it's not equivalent to a true sample. See this:https://docs.datomic.com/cloud/query/query-pull.html#limit-option

So probably the best way to return their ids mapped to the values in this type of mapping would be using tuples:

[:find [?tup-category (sample 10 ?tup-item)]
     :where [?e :category/name ?category-name]
            [(tuple ?e ?category-name) ?tup-category]
            [?e :category/items ?i]
            [?i :item/name ?item-name]
            [(tuple ?i ?item-name) ?tup-item]]