This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2022-01-12
Channels
- # announcements (2)
- # babashka (26)
- # beginners (48)
- # calva (32)
- # cider (23)
- # clj-kondo (61)
- # cljfx (3)
- # clojure (93)
- # clojure-australia (2)
- # clojure-europe (23)
- # clojure-losangeles (1)
- # clojure-nl (5)
- # clojure-uk (4)
- # clojurescript (46)
- # cloverage (9)
- # code-reviews (1)
- # copenhagen-clojurians (1)
- # cursive (39)
- # data-science (6)
- # datahike (8)
- # deps-new (8)
- # depstar (2)
- # etaoin (1)
- # fulcro (2)
- # funcool (2)
- # graalvm (5)
- # jackdaw (3)
- # java (17)
- # jobs-discuss (43)
- # kaocha (2)
- # leiningen (25)
- # malli (8)
- # minecraft (1)
- # missionary (8)
- # observability (6)
- # off-topic (37)
- # other-languages (12)
- # practicalli (1)
- # reagent (4)
- # releases (78)
- # remote-jobs (1)
- # sci (9)
- # shadow-cljs (13)
- # spacemacs (6)
- # sql (1)
- # tools-deps (30)
- # xtdb (3)
You can even use those json fields (or any jsonpath expression) for queries, and I think even indexing. Though indexing assumes you know exactly the shape of your data so if so, why put it in json?
"Schemaless" indexing works with JSONB, but only for equality and inequality - you create a GIN index on the whole field
https://blog.crunchydata.com/blog/better-json-in-postgres-with-postgresql-14 it seems that set operations also work now
We’re migrating from mongo to pg and jsonb plays a significant role in it. There are things that we don’t want to “model out” straight away, even though the data shape is known, so we just stick it in a jsonb blob for now.
We also have a concept of custom fields, and for now, they’ll be stored in a jsonb blob and their integrity will be handled by application code.
But where are the workers...? I can't believe it does that on its own... Did you try to ask workers?
My guess would be something to take core samples of the river bottom. Alternate guess would be laying some kind of pipeline.
I've only ever seen a worker on it one day, and he was too far from the edge of the river to be able to speak to him
Everyday though I see it in a different location. COuld very well be laying pipes, and the time of day I pass it (evening), the workers have gone home
There are so much stuff on that platform. They are definetly changing something at the bottom. Also if it would've been sample collection then they would need one diver guy on any boat.
What river is that @U013YN3T4DA?
I googled for lake and river "core" sampling barge
and clicked on Images, got a lot of photos that kinda look like that.
Which means those are not pipes and instead those are what they drill into the ground. Nice.
I love Scotland
Glasgow is a great place with great people
I’ve been thinking about exception handling recently, here’s a little something I cooked up:
(defn main [a b]
;; If do-a throws an ExceptionInfo with {:type :some-ex}, returns :failure
(trys'
(let [x (try' (do-a a)
{:some-ex (constantly :failure)})
y (do-b b)]
:success)))
Writeup, justification, and code: https://gist.github.com/maxrothman/f91ffccd8f2ba22618b2c699c8a8fbb1
Thoughts?I saw you mention this in another thread, and I thought I'd throw my hat in the ring and show what the same control flow would look like in https://github.com/IGJoshua/farolero , which produces something slightly more verbose but which I think is a little more clear about the control flow.
Oh that's really cool!
Glad to hear my work can be an inspiration for people. :)
for a project I'd work on, I would find the complexity of a conditional inside catch
to be less cognitive overhead, compared to learning two new try macro variants
also I've never had try/catch like that inside a handler, instead I have used a middleware that wraps the handlers and catches their exceptions
the errors are rarely handler specific, and usually cross their concerns, instead being in categories like "auth missing" / "db connection failure" / "remote api failure"
If all of your errors fit in nice global categories, then this probably doesn’t solve a problem you have
In the projects I’m currently working on, most endpoints have domain-specific failure modes that, while you can force them into global categories, I find that doing so makes it hard to tell what failure modes can occur in each endpoint.
https://github.com/cognitect-labs/anomalies#the-categories might be something to look it, I like it because it fairly clearly communicates how to respond to a given error
even with domain specific errors, I don't see why you couldn't put the exception catching in a middleware used with endpoints in that domain
but of course you find this solution clearer, I'm simply answering the question posed, those were my thoughts