This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # announcements (10)
- # babashka (7)
- # beginners (31)
- # boot (4)
- # calva (8)
- # chlorine-clover (19)
- # cider (12)
- # clj-kondo (27)
- # cljsrn (7)
- # clojure (68)
- # clojure-colombia (2)
- # clojure-europe (47)
- # clojure-italy (16)
- # clojure-nl (4)
- # clojure-spec (13)
- # clojure-uk (39)
- # clojurescript (103)
- # code-reviews (8)
- # community-development (2)
- # conjure (38)
- # core-async (37)
- # cursive (2)
- # datascript (1)
- # datomic (31)
- # figwheel-main (22)
- # fulcro (18)
- # jobs (2)
- # jobs-discuss (6)
- # juxt (3)
- # keechma (1)
- # lambdaisland (6)
- # malli (30)
- # meander (20)
- # off-topic (29)
- # reagent (1)
- # reitit (16)
- # shadow-cljs (4)
- # tools-deps (70)
- # xtdb (19)
I'm using Capsule uberjars, but I keep getting "Illegal reflective access by Capsule" warnings. I know that it's possible to disable them. But I'm curious - is there something similar to Capsule that doesn't do anything that creates such warnings in the first place?
@U2FRKM4TW What features of Capsule are you using? There are quite a few uberjar builders out there.
Yeah, I'm not using
clojure.xml myself, but some thirdparty lib does. Interestingly, the traceback created by
--illegal-access=debug is not very useful in that regard, but there's just one such lib that my project uses. I'll probably end up creating a PR at some point.
Regarding features - no idea. The only reason I started using it is because it's alphabetically the first one among others that https://github.com/juxt/pack.alpha supports.
And I just use it, it just works (and I haven't a clue on how). But given the nature of uberjars, I suspect that reflection is really useful for that, if not obligatory. Hence the question.
I was about to ask you what you'd recommend for uberjars, but I see that you maintain depstar, so I should probably give it a try.
It will surprise no one that we use
depstar at work to create all our production artifacts 🙂
I have an extremely low opinion of capsule, the layers of indirection they impose are silly if you only have java deps, and are not as well designed as docker if you have non-java deps
also the fact that capsule creates jars that can't be directly put on your classpath to run a repl that accesses the resources in the jar is simply offensive to me
with most uberjars
java -cp uber.jar clojure.main gives me a usable repl, breaking that is frustrating
Pittsburgh Code & Supply is looking for more people to respond to their Compensation Survey, does NOT need to be Pittsburgh local. They're especially looking for people who are often under-represented in tech. https://codeandsupply.co/survey?from=personal
I hope Datomic becomes open source, this would be the easiest way to show the added value of Clojure philsophy in many projects.
Certainly making it 100% free would increase it's usage, but would that make Datomic better? Would that foster more support contracts? Would the economic return for the hard work of creating the product be returned to its creators? I dont undstand the econmics enough... but as a user I wish I could use it everywhere with wild abandon.
Hmm, now that they aren't going to do any consulting anymore, that might even happen
We expect the future for Datomic to be "like today, but more so." Datomic development, product offerings, and customer relationships will continue and grow, as they have.
I have been using Crux for the past 5 months or so and I am extremely happy with it. Having used datomic "in anger" (for work) where I ran into a few issues where my ability to debug bottomed out at the compiled bytecode of datomic, I was ecstatic to see that crux is open source. Its ability to be used in systems ranging from a single node to a full kafka fleet means I am happily all in on crux for the foreseeable future for projects large and small. Can highly recommend!
I have been looking for a schemaless datastore and the only thing that keeps me away from that are references across entities. Can you resolve / join them reasonably with Crux? I am especially interested in common stuff like entities per user.
Yep that works just fine but your traversal logic is in the application or library layer, since something has to be aware of the shape of your data.
I store references as either IDs or "idents"
[:entity/id #uuid "id123"] and then invoke
crux/entity on that id or ident when traversing references.
It is also in the application layer where you have to enforce that references are not transacted as nested entities (maps) and are instead stored as ids or idents. I think a common pattern for crux use is a layer in your application code that enforces your schema constraints - this is at least the design I landed upon. I am very happy with this trade-off because you get extreme agility in evolving your data system, combined with spec or malli at the data layer you can add on schema constraints as much or as little as you wish.
For executing queries, in my application I am using pathom to perform the id->entity traversal, but I also created a pull api (https://github.com/dvingo/my-clj-utils/blob/master/src/main/dv/crux_pull.clj) that is client code on top of the base crux API, so you can use that if pathom doesn't fit your needs. Both of these solutions support graph traversal/unbounded recursion which as far as I can tell are not present in any storage + query system other than datomic
Thanks for your explanation, nice to hear that. I think a lot of database logic is mirrored in application code either way, so I never saw that as a big disadvantage. I tried datomic a few years back when it was pretty new and loved it, it's just that there was no real open source option that drove me away.