This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2021-01-18
Channels
- # adventofcode (69)
- # babashka (21)
- # beginners (246)
- # calva (49)
- # chlorine-clover (19)
- # circleci (3)
- # clj-kondo (38)
- # cljsrn (1)
- # clojure (52)
- # clojure-australia (2)
- # clojure-europe (41)
- # clojure-nl (5)
- # clojure-spec (4)
- # clojure-taiwan (2)
- # clojure-uk (28)
- # clojurescript (12)
- # cryogen (6)
- # cursive (6)
- # datahike (3)
- # deps-new (5)
- # fulcro (2)
- # garden (1)
- # graalvm (3)
- # hoplon (48)
- # jackdaw (6)
- # jobs (3)
- # kaocha (6)
- # malli (3)
- # off-topic (51)
- # rdf (1)
- # reagent (40)
- # reitit (32)
- # remote-jobs (1)
- # reveal (24)
- # shadow-cljs (21)
- # startup-in-a-month (5)
- # xtdb (8)
I'm trying to refactor the code in "Web Development with Clojure, 3rd Edition" to use Crux instead of Postgres. I'm running into one area where I don't fully know what to do. In the book, the example application is a simple social network, and I'm trying to represent a "boost," a data type that represents a "retweet" or similar. I have two questions around this, the first is a sanity check--I'm representing a boost as a separate entity from a post, like so:
{ :post-id post
:booster user }
Does this seem like a reasonable way to do it?I'm struggling further when I try to query a list of posts and left outer join a list of users who "boosted" it. It's fairly simple to inner join it, but we might have a post that has no boosts, and I don't know how to do that query effectively.
Hey @UTECZMYPJ 👋 I'd recommend trying the EQL projection functionality - have a look at https://opencrux.com/reference/queries.html#eql-projection
essentially, you split your query into two - the :where
to narrow down to your list of posts, then the eql/project
to declare what data you'd like about those posts
I noticed that eql/project comes with an Alpha warning in the docs. Would you recommend using it at this point or is it still very likely to change?
@U01DH13SK8E good question - we're happy with how it's turned out, so it's looking like moving to a stable API in the next release or two, in its current form. It's getting a couple of additions to bring it closer to the EQL spec (unions, recursive queries) as well as a few custom parameters.
The one breaking change is that we're considering renaming it to pull
so that queries are more portable between Crux, Datomic and Datascript
Okay, that sounds great. And that would be an easy change to implement regardless. Sounds like that would be the way to go. And yay, for making the api more comparable!
Thank you in advance for your help.