This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2021-02-23
Channels
- # announcements (11)
- # architecture (14)
- # babashka (34)
- # bangalore-clj (8)
- # beginners (108)
- # calva (10)
- # cider (19)
- # circleci (9)
- # clj-kondo (19)
- # clojars (4)
- # clojure (62)
- # clojure-australia (2)
- # clojure-europe (62)
- # clojure-italy (14)
- # clojure-nl (8)
- # clojure-poland (1)
- # clojure-spec (14)
- # clojure-uk (59)
- # clojurescript (14)
- # community-development (5)
- # conjure (2)
- # core-async (10)
- # cryogen (1)
- # cursive (11)
- # data-science (1)
- # datahike (13)
- # datomic (21)
- # deps-new (4)
- # ethereum (1)
- # events (4)
- # fulcro (34)
- # helix (2)
- # jobs (2)
- # juxt (33)
- # kaocha (4)
- # lsp (18)
- # malli (4)
- # membrane (2)
- # off-topic (23)
- # re-frame (3)
- # reitit (4)
- # remote-jobs (1)
- # reveal (6)
- # shadow-cljs (47)
- # slack-help (2)
- # spacemacs (5)
- # sql (45)
- # startup-in-a-month (6)
- # testing (4)
- # tools-deps (21)
- # xtdb (4)
quick point of feedback on return maps: I know that the upcoming release does it the datomic way, but would it make sense to just have a single top-level :keys
clause and just naively zipmap the specified vector, instead of always inputting symbols and converting it based on the keys/strs/syms
clause? some benefits that come to mind: 1. mixed return types 2. support other key types, like ints 3. save a few cycles on checking/conversion 4. less confusing for non-clojure languages? keys/syms/strs seems like a distinction that wouldn't exist outside of clojure 5. as with the last point, avoid conflation of keys
with keywords? 6. one fewer clause to quote if you aren't quoting the whole thing and just want keywords/strs
Thanks for taking a look, feedback like this is always welcome 🙂 I definitely see that for JSON-only users the choice of the word :strs
would seem pretty obscure. I'll make sure we give this some thought soon although probably only after the next release. We can always add another option to the query map, perhaps :return-keys
, for the more loosely typed behaviour you'd prefer
to be clear, it's not a requirement or anything on my end, just sharing thoughts. thanks for making us all feel welcome :)
Evening folks, 1.15.0 is out 🚀 🎉
- We've made the Java API for submitting transactions much more IDE-friendly - Java users can now construct transactions programmatically through the new Transaction APIs rather than needing to know about Clojure data structures. Big thanks to new JUXTer @aon and (not so new JUXTer) @dan621 for this one. There are a number of deprecations and a couple of breaking changes here for Java users (and, by extension, Clojure users accessing the Crux API via Java interop rather than through the crux.api
namespace) - check out the release notes for more information.
- Another oft-requested feature: queries can now return maps, using the :keys
/`:syms`/`:strs` syntax as in Datomic/DataScript. (admittedly @kevin842 beat me to this one by a few hours 😅)
As always, more details at https://github.com/juxt/crux/releases/tag/21.02-1.15.0.
Cheers 🙂
