This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2016-11-10
Channels
- # aws (45)
- # bangalore-clj (16)
- # beginners (109)
- # boot (137)
- # cider (7)
- # cljs-dev (54)
- # cljsrn (22)
- # clojure (77)
- # clojure-conj (1)
- # clojure-greece (2)
- # clojure-nl (5)
- # clojure-russia (36)
- # clojure-spec (15)
- # clojure-uk (54)
- # clojurescript (118)
- # cursive (7)
- # datomic (25)
- # emacs (33)
- # hoplon (276)
- # klipse (38)
- # lein-figwheel (1)
- # leiningen (9)
- # melbourne (1)
- # off-topic (18)
- # om (98)
- # onyx (6)
- # pedestal (1)
- # perun (24)
- # re-frame (46)
- # reagent (6)
- # ring-swagger (3)
- # spacemacs (67)
- # specter (15)
- # untangled (33)
- # vim (6)
is query/transact supported for :db.type/bytes
through the REST API? I’m getting back a #object["[B" 0x43d8762c “[B@43d8762c”]
@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 🙂
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…
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”}
@mbutler thanks, will explore that as well
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.
@timgilbert why not just d/q
? might be faster as well
Hmm, yeah, maybe I should just build up my (d/q)
query dynamically.
What I am currently working on is this:
(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)))
…but I need to get the first function into tail-recursive form
@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.
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
@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.
@misha: no, will try a d/q implementation out and report back though
I think, comparing 3-5 attribute-long pull and query should be enough to get an idea, before jumping to implementation
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.
our first idea was to use filtering but it was hard to do in a general and performant way
Yeah. The pull patterns themselves are arbitrarily nested too, which makes validating them potentially tricky
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.
I look forward to checking out your library 😉