Fork me on GitHub
#datomic
<
2016-11-10
>
csm01:11:50

is query/transact supported for :db.type/bytes through the REST API? I’m getting back a #object["[B" 0x43d8762c “[[email protected]”]

karol.adamiec09:11:56

@timgilbert well for now i need to stick to javascript. Using datomic as backend though gives a nice migration path 🙂 , what is kind of a goal that i am going towards. transit looks exactly right, will try to use it to translate from EDN into json 🙂

karol.adamiec10:11:35

looked over transit-js tutorial. There is no answer for wierd keys there really, unless a customized handler for a tag is used. Could piggyback on that…

Matt Butler13:11:43

On a slightly related note to Tim, can you get the Pull API to return a just the value similar to how you can with the query API (scalar) instead of storing the result in a map.

(d/pull db [:name] Jeff's Entity)

=> “Jeff”

Rather Than:

=> {:name “Jeff”}

karol.adamiec14:11:16

@mbutler thanks, will explore that as well

devth16:11:00

hi all. is there any interest or has anyone worked on a lib that operates over pull patterns? considering set operations like difference, intersection, and union. my particular need is for an ACL implementation. access rules are specified as pull patterns. these need to be combined into a single pattern to determine the set of all attributes a subject entity can access. when the subject submits a pull query it needs to be validated against that access pattern - essentially you take the intersection of the requested pull query and the access pull. also open to feedback on whether this is a good/bad approach or alternative ideas, of course.

misha17:11:14

@mbutler (:name (d/pull db [:name] Jeff's Entity)) kappa

misha17:11:07

@timgilbert why not just d/q? might be faster as well

misha17:11:39

@mbutler if you need a single value, d/q will work for you too.

timgilbert17:11:19

Hmm, yeah, maybe I should just build up my (d/q) query dynamically.

timgilbert17:11:11

What I am currently working on is this:

timgilbert17:11:22

(defn- make-pull-navigate-pattern
  "Turn a seq [:a :b :c ... :z] into a pull pattern [{:a [{:b [{:c ... [:z]}]}]}]"
  [path]
  (loop [[head & tail] path]
    (if (empty? tail)
      [head]
      [{head (recur rest)}])))

(defn navigate
  "Given a path of references from one datomic entity, walk the chain of them and return
  the final attribute in the chain."
  [db item path]
  (let [pull-pattern (make-pull-navigate-pattern path)
        results (d/pull db pull-pattern item)]
    (get-in results path)))

timgilbert17:11:49

…but I need to get the first function into tail-recursive form

timgilbert17:11:33

@devth: we have talked about doing stuff like that but haven’t got much progress to report. Some of our APIs let the client send a pull pattern over, and it doesn’t seem obvious how to implement a security system on top of that.

misha17:11:18

did you compare its d/pull execution time to generated d/q one?

timgilbert17:11:02

You can use the datomic filter operations to limit data at an attribute level, but more semantic “user x needs to be in group y to access data set z” operations don’t seem to be easy to do without some vetting at the server level

devth17:11:13

@timgilbert that's what I'm aiming to do too - let the client send a pull pattern over - then intersect that with access control pull patterns to limit what the client actually retrieves.

timgilbert17:11:31

@misha: no, will try a d/q implementation out and report back though

misha17:11:31

I think, comparing 3-5 attribute-long pull and query should be enough to get an idea, before jumping to implementation

timgilbert17:11:16

Yeah @devth, it seems tricky to do. One thing we speculated about but did not try was using the “as-if” facilities to restrict a database value to only the set of what a given user could see. It didn’t seem likely to be performant, but we never really tried it out.

devth17:11:08

our first idea was to use filtering but it was hard to do in a general and performant way

timgilbert17:11:57

Yeah. The pull patterns themselves are arbitrarily nested too, which makes validating them potentially tricky

devth18:11:39

if you had a way to reliably do (intersection access-rules-pattern client-request-pattern) then you're good. as long as they are rooted at the same subject entity the algo to do that isn't overly complex.

timgilbert21:11:15

I look forward to checking out your library 😉

devth22:11:06

🙂 will definitely post if/when i figure it out