This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # aleph (1)
- # announcements (14)
- # aws (8)
- # babashka (3)
- # beginners (49)
- # cider (6)
- # clara (7)
- # clj-kondo (58)
- # cljs-dev (17)
- # clojure (65)
- # clojure-dev (45)
- # clojure-europe (5)
- # clojure-italy (4)
- # clojure-nl (25)
- # clojure-norway (3)
- # clojure-uk (68)
- # clojurescript (10)
- # cursive (5)
- # datomic (12)
- # emacs (24)
- # fulcro (149)
- # hoplon (56)
- # kaocha (2)
- # luminus (18)
- # malli (7)
- # off-topic (12)
- # other-languages (82)
- # reagent (16)
- # reitit (7)
- # shadow-cljs (44)
- # spacemacs (4)
- # tools-deps (48)
- # xtdb (17)
Has anyone used migratus with postgres where in a migration has multiple ddl statements in the same migration file? This is my migration file
I have done as this link suggests - https://github.com/yogthos/migratus#multiple-statements, i.e add
CREATE INDEX foo ON baz USING GIN(col1); -- GIN Index (array) --;; CREATE INDEX foo1 ON baz USING GIN(col2); -- GIN Index (array) --;; CREATE INDEX foo2 ON baz USING GIN(col3); -- GIN Index (array) --;;
--;;after each statement. But I get this error
Execution error (PSQLException) at org.postgresql.jdbc.BatchResultHandler/handleCommandStatus (BatchResultHandler.java:92). Too many update results were returned.
I use migratus, and
--;; works fine for me.
One suggestion - maybe
CREATE INDEX with
GIN returns more than one row? If so, you can try wrapping each statement in
Even if that doesn't work, it's helpful when you need to execute some function that returns something but you only needs its side-effects.
DO $$ BEGIN [... your statement here ...] END $$;
So far I found https://flywaydb.org/ the best for migrations. There is Clojure wrapper. But I was checking possibilites last time 1-2 years ago.
I'm perfectly fine with migratus so far. It's pretty simple, allows SQL and CLJ migrations.
@U2FRKM4TW will give it ia try.
@U2FRKM4TW you were right.
Create Index with
GIN was returning multiple rows. Wrapping each statement in
DO did the trick. Thank you:)
I’m using selmer templates… is there a way to pull a value out of hashmap based on another variable? In most templating laguages you can do something like this
my_map.keyvar but the value of keyvar should be used instead of the name
@roklenarcic Pretty sure we ended up writing our own "getter" for that situation... let me check...
Yeah, we wrote a
and use it like this:
(selmer-f/add-filter! :get (fn [m k] (get m k)))
so it deferences
page.pageIdand uses that value as the key within
params.children-- looking at it, I think we are only using it in resources, not filters, and we have additional code to dereference values in resources (any arg beginning with
@) so I don't think the above is sufficient on its own...
hello y'all. Everytime I run my jar file I get this obnoxious warning. I know they are harmless but I don't like them. How can I remove then
WARNING: An illegal reflective access operation has occurred WARNING: Illegal reflective access by org.xnio.nio.NioXnio$2 (file:/home/stlalo/Workstation/com.bayzyen.ingest/target/com.bayzyen.ingest.jar) to constructor sun.nio.ch.EPollSelectorProvider() WARNING: Please consider reporting this to the maintainers of org.xnio.nio.NioXnio$2 WARNING: Use --illegal-access=warn to enable warnings of further illegal reflective access operations WARNING: All illegal access operations will be denied in a future release
You can't, until that library you are using is updated to be more compatible with Java 9+
@contact904 You may want to check if there's a more up-to-date version of the library you're using...
you could try
--illegal-access=deny - this actually provides more feedback to the Clojure reflector and it will look up the chain, possibly finding a public interface that does not violate the module constraints
Hi I am new to Clojure In https://clojure.org/reference/java_interop#typehints it says "Normally, one should avoid the use of type hints until there is a known performance bottleneck." In what way can it be a bad idea to use type hints? I am considering using them everywhere - why should I not? I'm thinking that if type hints were required, it would be possible to improve IDE support.
just the general, "why say stuff you don't have to"
I don't know the detailed status of whether various tools leverage type hints for completion etc
Well, maybe they do, but not statically
I think it is misleading to write that something should be avoided if the reason is in fact: you don't have to - sorry
"your code will be more difficult to read for the community or experienced clojurists that you hire"
Well - maybe I should look for another language :face_with_rolling_eyes:
I think new Clojure users tend to over-hint and this more speaks to that? Also, hints are just that, and if they are wrong, the code can still work reflectively, so in that, maybe unusual, case it's like having old comments that are no longer in sync with the code
I tend to usually write my code to be warning free as well, and that's certainly not a bad thing
I would like warnings and error to be shown
*warn-on-reflection* true and
*unchecked-math* :warn-on-boxed can be handy. Personally I run them only in CI, informatively.
there are some very good linters now that can be integrated into your toolchain, like joker or clj-kondo
I have looked at Elm too - apparently they guarantee that you will NEVER experience run time errors because that language has quite the opposite attitude regarding type hints
I have tried to force a runtime error - I could not
(when there were no static errors)
Actually, I am impressed by Clojure and most of the documentation, but this seems like a weakness
It's a trade off. Languages like Elm and Haskell take a very different approach to Clojure. Some folks like static types, some don't.
Why don't you like static types?
fwiw clj-kondo does use type hints to statically warn you about mistakes like
(defn foo [^long x]) (foo "not-a-long")
it's provably impossible for a language to be able to statically prevent all possible errors. that said, static typing certainly does prevent some class of errors. clojure is a dynamic language and the people who write it and most of those who use it believe that the class of errors prevented by static typing is usually not worth the cost of static typing. we all respectfully agree to disagree, basically. it's definitely worth every programmer's time to try both styles extensively to see how they feel about it
This discussion should probably move to #other-languages if we're going to wander off from discussing Clojure itself...
I'm not saying that you should litter your code with type hints, but if they're there, why not use 'em
@jakob.riishede.moller Probably an interesting talk to watch: Maybe not, by Rich Hickey, the author of Clojure. He explains a couple of "costs" of type systems, where they get in the way. It's not all black and white: type systems have benefits, but also costs.
Do you have a link?
@borkdude You're also welcome to come over to #other-languages to continue the discussion.
is there anything resembling a security oriented static analysis tool for clojure?
@lkschubert8 what kind of things would you like to discover?
really any of the owasp top ten
clojure's use of macros make that sort of thing more complex it seems - I haven't seen an equivalent for the java tools personally
many of those aren't specific to Clojure: hit an HTTP endpoint maliciously and see what happens
that's not static analysis though
there are known dependency vulnerability scanners for the Java ecosystem - can reuse those
@ghadi Do they operate at the bytecode level? If so, you'd need AOT'd Clojure code, right?
the dep analysis ones just check versions
the ones that operate at a bytecode level would be checking for SHA256(classfile) being in a naughty list
there are source analysis tools but those don't use bytecode, they use java conventions and complain about code that doesn't follow them
so less useful for clojure, more useful for clojure pulling in e.g. a bad jackson version
some tools are things like https://github.com/livingsocial/lein-dependency-check or https://github.com/rm-hull/lein-nvd that use the owasp dependency check java tool
note that I've seen cases where these incorrectly flagged the wrong clojure dep too, so you have to double-check the feedback you get. I've filed some of that stuff back to Dependency Check and its been fixed since.
there are no static analyzers that specifically check for Clojure violations of owasp type concerns afaik
java source code analyzers don't do anything for Clojure. java bytecode analyzers (like FindBugs) usually create an enormous number of false positives and end up relatively worthless in value per time
an excellent talk on how OWASP applies to Clojure was given at EuroClojure a few years ago: https://www.youtube.com/watch?v=lRHPZXKQVLk
Thanks everyon. I'm going to dig through all of this, but it seems like I should be able to cover our needs.