Maybe ask in #C03RZMDSH if you get no response here by tomorrow...

thank u.

You missed redacting the password in a second place on the screenshot

I suspect the url you are passing is meant to point to the transactor process, not the underlying storage (postgresql) that is a guess because the stacktrace with the error is coming from the message bus code that datomic uses to communicate between peers, which isn't code you would pass a database url to

https://docs.datomic.com/pro/other-tools/console.html the docs here say it should be the transactor URL without the db

@U0612UCP14J I removed the file where the password was visible, please reupload a properly censored version if your problem isn't fixed and maybe change that password.

you can create user.clj somewhere in classpath and add (ns foo) at the end

No official approach to setting a namespace in Clojure. Leiningen uses a hack. Using the -e option is the hack for Clojure CLI (setting ns in a custom user namespace doesn't guarantee it's called last during startup - it usually isn't so this approach is unreliable) Given there are many ways to avoid having to set the namespace on startup, it's curious as to why so many people ask about this. https://practical.li/clojure/clojure-cli/repl-startup/

My projects use a Makefile to manage my repl server. It starts a lein repl :headless & in the background and writes a .nrepl-pid in addition to the .nrepl-port. I use make nrepl to start it. If an nrepl is aready running, make nrepl prints the port number it's running on. The make nrepl-stop command kills the process. And make repl does a lein repl :connect to the nrepl. I use that for off the cuff evals and once in a while to make sure my Calva repl state isn't lying to me. I also run make test which runs lein test before pushing commits to make sure the tests pass from a clean state.

@U04V70XH6 I generally only work on 1-2 projects at a time. I jack in from the editor, the REPL-buffer pops up, and if I could just type (start) there it would be convenient. But it is certainly no big deal. I think a big part of me even asking this question is that this is the last feature of lein that I miss. If I hadn't used lein before, I don't think I'd have thought about it.

Of course.

E.g. inserting a record with NULL in some columns using HoneySQL.

Any case using the (keys m) function. Or the default value arg (:foo m :default)

yup... ive dealt with some data where nil was a meaningful value for a key, so (contains? some-map some-key) was meaningful

> yup... ive dealt with some data where nil was a meaningful value for a key, so (contains? some-map some-key) was meaningful nil meaningful how? does it mean something other than an absence of a value?

measured absence is distinct from absence of knowing, no?

Let’s say you destructure with {a :a :or {a 0}}. For {:a nil}, a will be nil. For {}, a will be 0.

The question is worthy, but it should be pointed out that it isn't especially related to Clojure.

@U04V70XH6 that's a nice example! I think its important even when reading. For me if a key isn't present in map, it means the query didn't contain that projection. If the key is present but is nil, it would mean that the value of that projection is nil. An important difference!

in short you do {:vat-id nil} when value is empty and {} when there was no value for :vat-id in input at all. Consider for example API input. There is a difference between request with missing field (wrong request) vs company which doesn’t have vat id, so set it to null by intention. Also when you get data from this party sytem, there is the same scenario in response. or historical data, for example field X was added in 2022, but didn’t exist in 2021. So missing value vs X nil will have different meaning.

The question is: can you simplify your “model of the world” and only go with {} ? Do you truly need that case of a missing field/wrong request? I get that you can “assign” difference in meaning for the different cases like {} and {:vat-id nil} . The question I always ask myself is: is that separation/extra possible states truly necessary to solve my problem?

Fewer data state(s) are always better, all things being equal 🙂

of course when there is no difference, then there is no reason to do it. But the question was > Is there any real-world scenario So I gave an example.

The reason behind that stuff is data validation. Especially for API.

this also let API respond with error and “vat-id missing in request” while “vat-id” can be nil. But assuming vat-id is nil, because was not in request can be wrong. It makes it more user friendly for developers who integrate with API.

if you describe your data in any kind of schema like spec, then you can respond with very nice and readable feedback for developers what fields they need, what is missing, what is wrong, what fields are obligatory etc. So this is another example of use. This time to make better experience for developers.

Databases on one end (as I mentioned) and API input on the other end as Krzysztof mentioned. In both cases, the semantics of missing vs present-but-null may be important. Inside your pure Clojure world, you can work with a data model that makes "missing" and nil the same, but you need that distinction when working with the real world "out there"...

It's important to understand that the style guide is not official, and many of its suggestions are not widely held

Yeah, I definitely disagree with that part, among others.

I would only prefer :pre and :post to asserts at the very start and at the very end of the function. Which :pre and :post add themselves.

right...I kind of got that feeling when reading through it. I guess I personally agree with most of the guide but some things in there are not even in accordance with clojure.core which I would assume is "correct" in some sense.

one good reason pre & post are rare is that they implement a specific style of programming which is not appropriate for the general case https://docs.oracle.com/javase/7/docs/technotes/guides/language/assert.html

I believe the core team explicitly states that clojure.core does some wacky stuff and should not be taken as an example of style

ha : )

some things in there are not even in accordance with clojure.core which I would assume is "correct" in some sense.But only in some. There are definitely instances where the code would've been written differently were Clojure created yesterday.

ok duly noted

as to the original Q 🙂 for the general case I prefer something like when-not blah-blah throw (IllegalArgumentException.)

In this particular case I was for example thinking of this:

;; better 
(ns examples.ns
  (:require
   [clojure.string :as s :refer [blank?]]
   [clojure.set :as set]

;; good
(ns examples.ns
  (:require [clojure.string :as s :refer [blank?]]
            [clojure.set :as set]

@U05092LD5 yeah, that is what I tend to do as well

FWIW, I just throw ex-info most of the time.

which you also can not do if using pre/post conditions

How are pre/post related to the ns form?

not at all, I was just referring to the recommendations in the guide vs for example clojure.core

anyway - thank you for the clarifications and especially interesting with the perspecitve on core and the winds of history