This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2019-11-15
Channels
- # announcements (1)
- # aws (79)
- # babashka (47)
- # beginners (82)
- # calva (65)
- # cider (27)
- # cljdoc (18)
- # cljs-dev (29)
- # clojure (189)
- # clojure-dev (5)
- # clojure-europe (3)
- # clojure-italy (1)
- # clojure-madison (6)
- # clojure-nl (4)
- # clojure-spec (10)
- # clojure-uk (41)
- # clojured (3)
- # clojurescript (5)
- # clojurex (17)
- # cursive (30)
- # data-science (7)
- # datomic (17)
- # emacs (3)
- # events (6)
- # fulcro (2)
- # funcool (9)
- # graalvm (29)
- # jobs-discuss (3)
- # joker (3)
- # kaocha (6)
- # malli (5)
- # music (6)
- # off-topic (21)
- # reagent (3)
- # reitit (4)
- # rewrite-clj (8)
- # shadow-cljs (49)
- # spacemacs (7)
- # sql (23)
- # tools-deps (15)
- # vim (43)
- # xtdb (19)
are there any plans to make crux use tick (when that's stable) or something other than clojure #insts (i.e., java.util.Dates)?
Tick can be used to construct java.util.Date in an app but I don't foresee tick being part of Crux core.
There is some overlap between Allen's interval algebra and bitemporality beyond point in time, but that's further along the roadmap
I'm getting the following when trying to read edn data to bootstrap some in-memory DB: No reader function for tag crux/id. at some point earlier today I could read that alright without explicitly installing whatever reader extension is needed for that. how do I make sure that's installed by the time I initialize my test DB?
OK, I got it working by passing {:readers {'crux/id crux.codec/id-edn-reader}} explicitly to clojure.edn/read-string. not sure if this is how it's meant to be done
Interesting :thinking_face: I haven't seen this workaround have to be used before. Are you using lein? Which version of Crux are you using?
I suppose it's not dissimilar to how we have done this in crux-http-client https://github.com/juxt/crux/blob/574d0091f48cd39109b3d32f1178962a1a7da505/crux-http-client/src/crux/remote_api_client.clj#L18
my understanding of how the readers work is sketchy at best, but it sounds like this is worth a note in the docs
is it by design that crux is trying to verify my transaction data against any specs I have installed for the relevant keys, or is that a side effect of crux trying to verify its own specs?
my specs are against some denormalized form of the data, so they're not accepting the normalized form I'm passing to crux
I guess I could use different namespaces for the normalized data or something; just asking whether this is a bug or a feature is all 🙂
@euccastro interestingly, someone asked a similar question on the Zulip last Saturday which I just responded to 🙂 (I assume you're not connected...?) - see https://juxt-oss.zulipchat.com/#narrow/stream/194466-crux/topic/spec.20attributes -- but to answer your question here, Crux validates the txs itself so this is an expected side-effect (aka a "feature") though if you have strong opinions that it should work differently then we would be happy to explore options in a GitHub issue (or even if you want to discuss your workaround idea)
no strong opinions; just curious. I am not connected to the zulip, no; will do so now. thanks!
Hi, is there a Docker image with crux / rocks DB I could just start using right away?
@U0GE6JTKK hey! The current Docker image is a little stale, though it will do pretty much what you want. We can re-publish with the latest version of Crux on Monday. Are you looking to only use the HTTP API? Here are the details on the image: https://github.com/juxt/crux/tree/master/docs/example/standalone_webservice