Clojurians Log v2
announcements
I’ve just released new version of Penkala (0.0.3) - a composable query builder for PostgreSQL. Now with the support for insert, update and delete queries https://github.com/retro/penkala
hi @mihaelkonjevic , thanks for bringing fresh perspective on sql to clojure community. I am grateful that Walkable is mentioned in penkala's readme. However, I think the statement "eschewing SQL and instead use EQL to write the queries" does not describe Walkable. I guess that's your experience with exoscale's esql, but esql and walkable are not the same
Walkable exposes EQL for clients, but also have an adaption layer (that are hidden from clients) where you can use s-expressions (something like honeysql) to build SQL constructs https://walkable.gitlab.io/walkable/1.3.0/s-expressions.html
I hope that clears the confusion. Anyway, congrats on the release
@myguidingstar thank you for letting me know. I’ve played around with walkable during the last year (and read the docs multiple times), and I completely missed the s-expressions part. Is that a new thing? I’ll update the readme and link to the s-expressions docs 👍
no, the feature is part of walkable's core design and has been around for two years https://github.com/walkable-server/docs/blob/master/s-expressions.md
thanks for your collaboration
@myguidingstar https://github.com/retro/penkala/commit/9749ae3ec3fc279eb0c7f2647e868cd2b489df34
I made a simple library that allow you to stop core.async go loops: (only deps.edn :sha at the moment): https://github.com/saberstack/loop
I've made a jackson-jq wrapper for Clojure. The intended use case is to embed jq scripting into GraalVM native-images. https://github.com/dainiusjocas/clj-jq
Helper pack for core.async with focus on error propagation https://github.com/jtkDvlp/core.async-helpers
Well if we're sharing core.async libraries, I'll share one I've been developing for a while: more.async: Small composable independent machines. Oriented towards building processing pipelines What is it trying to solve? I've seen too many times people reinvent the wheel at several points when building core.async processes: • producing into processing pipelines and consuming from them • batching • routing to channels • circuit breaking more.async is an attempt to solve those issues once and generically, instead of many times and ad-hoc. https://github.com/bsless/more.async
Do you recommend not using periodically! and reductions!?
No reason not to use either, as both have their uses @phill
Perhaps make a request to include this in https://github.com/clojure/core.async/wiki/Libraries
> last edited 2015 I had no idea that page even existed =/
I (very) recently had a change accepted to add more.async to https://www.clojure-toolbox.com/
😮 thank you!
I'm working on a new stream processing engine in Clojure, inspired by Riemann, which can be used for monitoring for example. It's still a work in progress project but I opened the repo and did an article explaining the project: https://mcorbin.fr/posts/2021-03-01-mirabelle-stream-processing/
Very interesting, merci! Your mention of logging got me thinking. Currently we send errors to Sentry for incident management/alerting but it is easy to exceed our quota when there is some temporary problem and the same error keeps repeating thousands of times. So I would like to put something in the middle, between our app and Sentry, that would limit the number of "repeated events" that get through. That would require writing an adapter that would expose Sentry-like API (so the clients can be used unchanged) and turned the events into the format Mirabelle understands. Next, I would need to define an event "fingerprint" so that I could detect what events actually stem from the same error condition (I guess some combination of the message and stack trace) and thus make a "throttling window" for each unique error. Finally, a sink that would pass the events that were not filtered out to Sentry. My question is: Would that be a reasonable use of Mirabelle (or some future version thereof)? Thank you!
@holyjak It should be possible indeed. Adding sentry support should not be that difficult (it's just an http client). Mirabelle already supports the Riemann "throttle" stream, which only send one to downstream actions evey N seconds
So imagine you compute a fingerprint and store it in a :fingerprint key in your event, you could do: (by [:fingerprint] (throttle 1800 ;; 30 min (push-io! :sentry)))
like that, each "fingerprint" has its own throttle
nice! thanks!
Pas mal du tout! I remember discussing Riemann with you years ago on IRC and how restarting and loosing state was indeed a pity. Glad to see the groove is still going!
thank you ;)