This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # architecture (1)
- # asami (25)
- # babashka (1)
- # beginners (1)
- # calva (23)
- # clj-kondo (54)
- # cljfx (23)
- # cljsrn (9)
- # clojure (72)
- # clojure-europe (2)
- # clojure-spec (16)
- # clojure-uk (4)
- # clojurescript (10)
- # code-reviews (1)
- # crux (4)
- # cursive (2)
- # datomic (1)
- # events (2)
- # exercism (2)
- # fulcro (6)
- # graalvm (1)
- # malli (1)
- # membrane (1)
- # off-topic (31)
- # pathom (3)
- # reagent (6)
- # reitit (2)
- # releases (1)
- # shadow-cljs (1)
- # vim (6)
- # vrac (25)
I am playing around with luminus and defined the password column in the users table as TEXT
because the library retrieves something like this:
:pass #object[org.h2.jdbc.JdbcClob 0x3aa10bc8 "clob2: 'bcrypt+sha512$914ff82438d740391603a9771bf05108$12$d06f3f7a38812e86accd15a690d3b4c5b05a34c0b8549431'"
maybe calling this method? https://github.com/h2database/h2database/blob/master/h2/src/main/org/h2/jdbc/JdbcClob.java#L92-L95
Something very similar is here: https://en.wikibooks.org/wiki/Clojure_Programming/Examples/JDBC_Examples#SELECT
The second stupid question would have been: how do drop and re-create the table with VARCHAR type by migrations? I didn't used it ever.
The following worked for me in Postgres - note that h2 seems to use slightly different syntax*
*h2 syntax (untested):`ALTER TABLE tableName ALTER COLUMN columnName SET DATA TYPE dataType` Btw, I can recommend https://pragprog.com/titles/dswdcloj3/web-development-with-clojure-third-edition/ for a detailed dive into. Luminus.
;; REPL (in-ns 'user) (create-migration "change-author-type") ;; <timestamp>-change-author-type.up.sql ALTER TABLE posts ALTER COLUMN author TYPE VARCHAR (300) ;; <timestamp>-change-author-type.down.sql ALTER TABLE posts ALTER COLUMN author TYPE TEXT ;; REPL (migrate) ; changes to VARCHAR (rollback) ; rollsback to TEXT
Can someone please recommend or comment on choice between
http-kit. I have been trying to avoid asking that question. I have looked at both and both seem nice to use. But I want to know from the perspective of (1) bugs encountered; a few days ago someone mentioned about experiencing deadlocks with
aleph. (2) which one is expected to be around for longer. (3) limitations such as being able to use other libraries with it, available middleware etc. (4) performance in production. Thank you.
We've run both Jetty and http-kit in production. We started with Jetty but saw occasional, unexplained "thread death" exceptions, so we switched to http-kit and it was fine, but support by monitoring software (New Relic) wasn't great so we switched back to Jetty (a more recent version), and it's been rock-solid in production for years.
http-kit are both special custom things and neither are as widely-used or as well maintained and well supported as Jetty. Last I saw,
aleph was not being maintained and Zach was looking for someone to take it over.
http-kit is in a similar situation, but slightly better maintained.
I want something that is easy to use with websockets. Also, while I don't understand this well, I think something that is async would be better in terms of the server's capability in terms of number of concurrent connections it can handle on a very basic server, say a $20 per month Digital Ocean instance.
Thank you. Any pointers on which libraries to use for websocket connections with Jetty? Thank you.
We're using netty directly for a WS-based app but that means a fair bit of Java interop (and heavy use of core.async). I wouldn't recommend that approach until you've got some serious production Clojure experience under your belt.
@U013U475882 core.async is pretty hard to use and complex on its own -- I see non-beginner Clojurians running into all sorts of issues when they're learning core.async 🙂 -- and netty with interop is also non-trivial on its own. So then you're combining two non-trivial things with asynchronous behavior. It's a lot of stuff to learn and get working, if you're also still struggling with a bunch of Clojure basics.
Yes, I would like to avoid that (using netty directly or erlang). But I need websockets for sure.
I can't say that I have. There is a common issue that when you don't consume an inputstream on error, this can cause resource problems, but I believe this is documented somewhere
I see that it is still in
alpha. Do you know anything about whether it will continue to be developed?
Yeah in 2019 IIRC. It’s a pretty advanced codebase and needs understanding of Netty as well.
It's a shame that some popular projects like http-kit or aleph lean on one or two maintainers and when they change jobs the project is pretty much stalled? But I guess that's how open source software in a smaller ecosystem works...
@hiredman Did we look at Aleph before starting down our own path with Netty/interop? Or did we just go straight to netty-socketio because that was a requirement imposed by our client's needs? I think the latter, but I can't remember how much exposure you've had to Aleph?
Ztellman does seems to intend to ship a 1.0 of aleph as of last week, so the alpha label is probably oversold https://github.com/aleph-io/manifold/issues/187#issuecomment-716048610
Given how many Contrib libs used to be 0.x.y or have alpha labels, that aspect would not worry me much in the Clojure ecosystem. Contrib was all moved to 1.0.0 releases purely to address perception, not because of any functionality or stability issues.
And clojure.java.jdbc is stable (no longer maintained) so that's 0.7.x (next.jdbc is the 1.0.0 that c.j.j never got)
Yeah, that maintainer hasn't cleared a 1.0.0 release yet. I think Alex was talking to him about it.
Different approach: why not use something like http://pusher.com and let someone else handle the hard parts?
Thanks everyone. Really appreciate all replies. Pusher is expensive for something that has revenue less than $500 per year :)
We've been riding the free tier for a long time. It's quite generous (unless it changed recently)
and there are alternatives, which compete with pusher on pricing, with the same feature set
Depending on your architecture and the application, that's technically 100 concurrent users