I'm not entirely sure what you're asking but I will point out that -T (and -X) invocation expect key/value pairs after the function name so you'd need a command line like:

clojure -T:build run-tests :selector :integration

Does that help @U8SFC8HLP?

@U04V70XH6 Somewhat. We’re currently not doing much at all beyond defaults, in fact our kaocha-within-build is directly grabbed from build-clj’s readme, so our understanding stopped at passing the argument in correct form within build.clj to bb/run-tests .

OK, so run-tests accepts all the same arguments that run-task accepts, so you can pass :main-opts as a vector of strings, containing additional values to be added to the :main-opts from the alias.

So you could just do:

clojure -T:build run-tests :main-opts '[":integration"]'

LMK if you need more information than that @U8SFC8HLP

@U04V70XH6 Ah, those work! 👍 Now I just need to fiddle around a bit since our full setup doesn’t work but that’s on our side. Also a bit shame that :main-opts has to be a string (vector of strings seems to work as well), but that we can live with.

Thinking back, we probably did hit that serialization step issue but without further context/reference just didn’t realize what’s going on.

:main-opts is a vector of strings.

Not sure what you mean about "serialization"...?

Well, can’t do [:foo] , has to be [(str selector)] . I’m in Clojure code, so it feels weird I need to do this.

Because -main functions only accept strings (in a vector).

....maybe with middleware

> This causes problems in the clients Sounds like those are new clients. So why not just stick to the obj['field'] accessing notation instead of the slightly more convenient obj.field?

In OOP languages (in this case: Swift, Kotlin, maybe Typescript later) it is common to map the requests and responses to objects. I’d like to provide a standard API that does not close this door for others

Using POJOs is not closing the door to others - on the contrary. But, assuming the decision to use namespaced keywords was the correct one - what happens when your payload has a/b and x/b? It will invariably be trading correctness for convenience. And later on, if the time comes when you knee deep in mud with sudden x_b and xB that came out of the blue, it will be trading correctness for "just one more crutch so it works for one more week." Been there, done that. Not fun.

Even if the assumption is wrong and using namespaced keywords is unnecessary in your case, you can get rid of them and solve 95% of your problems. However, there will still be potential cases of a-b, a_b, and aB - still mud. Now, if you have and will have total control over your API and it will never have anything beyond your control - that might be fine and that 5% might never pop up. You can see better from there.

It’s not necessarily trading for correctness. We can still validate the payloads before mapping them to our “domain” model (for a better word), and could even apply a spec on this – for a stable API, it is necessary to have a dedicated, decoupled data structure, anyways. I agree with you that the namespaced keywords in Clojure are an approach that works very well, but I’d also like to provide an API which is standardized and does not contain any surprises for developers who don’t know that there is Clojure running on the server. Edit: But although I don’t agree in all points, thank you for your answers, that’s a good additional perspective to have!

By "correctness" I don't mean the data correctness but rather the model one. When your data is a/b-c, it's not a-b-c or a_b_c or aBC or whatever else the common JSON API notation happen to be. It's still a/b-c. > I’d also like to provide an API which is standardized There are no standards here - just conventions based on convenience, that's it. But a mapping is indeed possible. My point is that, such a mapping is useful only as far as it gets you. As soon as you need something that's not entirely within the boundaries of that mapping, it immediately becomes a hindrance with a great potential of you never wishing you ever went that way. Pretty much same deal with ORMs, conceptually - such a great thing, on the surface and when you stay within its area of convenience. > does not contain any surprises for developers who don’t know that there is Clojure running on the server. The only way to guarantee it is to just serve a plain JSON data without any promises about what a key will not have. There are plenty of APIs that don't serve data that can be immediately accessed as obj.field after parsing - and that's totally fine.

Just to be sure we are talking about the same model, would you expect the API to have its own model, or are we talking about our applications internal model? Just because the key in our internal model is a/b, does not necessarily mean that the b in the model for the HTTP call is the same, does it?

It causes alot of issues when using stuff like C#, usually I convert it to something like underscore for C# to denote name spaced items, then use CamelCase for the rest

I'm talking about the model of the existing transit+json API that you already have. The internal model does not matter here. It's the simplest solution, to just not do anything about it. And it works great in so many cases. There are plenty of answers on how to parse JSON data in Clojure when the keys can have all sorts of symbols and not just the ones that can go into keywords. The simplest answer is always "just don't keywordize your keys". Same with DBs - if there's a doubt, just don't keywordize column/table names, or at least don't transform them in any way. Extra transformations incur extra assumptions incur extra work incur extra problems. Ones that you get stuck with, unless you make a v2 API.

Event_DurationInMinutes

Thanks for the input, really appreciate it! I guess I have to take a walk and think about some stuff a little more. I guess the declarative approach we took with reitit + spec + swagger + coercion made us mash up some things in general :thinking_face:

This has been discussed before, I think most recently as response to this article: • https://vvvvalvalval.github.io/posts/clojure-key-namespacing-convention-considered-harmful.html Related: • https://clojureverse.org/t/clojures-keyword-namespacing-convention-considered-harmful/6169/15 • https://www.reddit.com/r/Clojure/comments/hhyb26/clojures_keyword_namespacing_convention/ • https://clojureverse.org/t/should-we-really-use-clojures-syntax-for-namespaced-keys/1516/41

There are several competing views and trade-offs, so there is no clear cut answer; but maybe that gives you some more food for thought for your walk :)

I, for one, welcome our new Namespace Overlords. But if I were looking for examples outside of Clojure, perhaps someone has shared what really large federated GraphQL schemas look like; I would be surprised if it wasn't a bunch of "namespaced" types via LongCamelCaseNameAlaNSCocoaJava

Thanks for the links! I found the vvvvalvalval blog some minutes ago and think it describes my issues quite well, but I also saw a lot of great arguments in the comments

Just use unqualified keys no?

Also, in general, I have two spec. I've got a spec for my API designed around clients. And I have a spec for my internal models. And sometimes I'll even have another spec for my database.

@U0K064KQV that’s what I am planning. “External” spec with :req-un, and internal, namespaced spec

Even in OO, people almost never use their API objects internally, it's not considered a good practice to couple yourself to API concerns internally. And even more so, in OO, normally the generation goes the other way, your classes/objects are generated from the API spec itself, so if the generation ever changes even your internal code would be broken.

What I've seen in a lot of JSON APIs written in JS/TS is the grouping of values behind a single key to represent namespaces. As in

{
    "event": {
      "duration-in-minutes": 60,
      "description": "string",
      "timezone": "string",
      "name": "string",
      "start-date-time": "string",
      "organizer": "string",
      "invitation": "string"
    }
  }

{
  "namespace": {
    "key": "value"
  }
}

Thanks for the idea, @U0P0TMEFJ! It’s a good approach for structuring data, but I’m not sure how I would handle maps which contain keys from different namespaces, that could end in confusing hierarchies in the json :thinking_face:

This is currently more a toy/experimental project to see what I could do with SCI in postgres

Were you able to run more complex functions? How does it work? The clojure code is compiled via SCI to what?

SCI is an interpreter. you can give it access to any clojure library you want, as long as you include it

This project is compiled to a native binary which runs within postgres

I see, thank you: so it's the SCI interpreter itself that's compiled and integrated, and the clojure evaluation happens "on the fly"

yes

Mostly, I was wondering if this could be use to do some light transformation on a postgres TRIGGER

@UA7E6DU04 Feel free to try it out and bug me with questions

Anything special about it?

It is based fully on Loom/Virtual Threads, quite exciting though!

Built by Oracle itself :thinking_face:

> I will introduce Helidon Nima - new microservices framework which is built on top of a server designed for Loom with fully synchronous routing that can block as needed > I would guess the blocking synchronous routing is a big deal, maybe that's why it's part of it.

So did you try to Thread/sleep or something inside the handler?

No, i kinda moved on to the rest of my day after posting it here

they still haven't released sources or docs so its more frustrating than I want to handle right now

Nothing built-in. Gotta do it either manually with a few extra lines or use some library for it.

couple lines copied over with attribution from cemerick’s url package: https://github.com/cemerick/url/blob/master/src/cemerick/url.cljx#L48

Which doesn't support repeated params. But query strings are highly domain-specific (in the broad sense of the word "domain"), so that might be fine.

good point. I’m also a big fan of the ruby style for indicating params are collections with multiple elements

Yeah, but that whole area is pretty much unregulated. Even when it comes to plain kv-pairs, the query format is not standardized in any way in the context or generic URLs. Might even have a base64-encoded string of msgpack'ed transit data in there as the whole query. :)

https://github.com/ring-clojure/ring-codec/blob/master/src/ring/util/codec.clj#L154

thanks everyone!

thinking more about it, an elixir keyword list like object would be just about perfect for parsing query strings

oh well, I just pulled in lambdaisland/uri since it makes what I'm trying to do more convenient in other ways too

Because within let, the names are bound to the values only after the values are evaluated. You might wanna use letfn, BTW. But depends on your use case. The bottom option is also fine, especially if you mix regular values with functions within the same bindings vector.

you could also use recur

The syntax for letfn feels weird next to the rest of the ways of uses of let or fn. And it doesn't provide for non-function bindings. Gets totally unreadable quickly when outside the very specific case of multiple functions but no other bindings.

(let [x 1]
  (letfn [(foo [y]
               (+ x y))]
    (let [z (foo 2)]
      (letfn [(bar [q] (* z 4))]
        (let [r 6]
          (bar r))))))

(let [x 1
      foo (fn [y] (+ x y))
      z (foo 2)
      bar (fn [q] (* z 4))
      r 6]
  (bar r))

Yeah. I like the recur option. 👍 Although not all recursive functions can reasonably be made tail recursive. Question really was about the how/why of binding situation: Naming an otherwise anonymous function gives it a binding available from within itself. While naming it in the let does not.

The naming for recursion inside fn is unrelated to the let binding, you could use different names for each for example.

You can also wrap it yourself in an atom (or maybe a promise as well).

(let [foo (atom nil)
      _   (reset! foo
           (fn[a] 
            (println a)
            (when (true? a)
             (@foo false))))]
 (@foo true))

(let [i (+ i 0)] ...)

That's why there's letfn, it solves this exactly for fns only, but it's more for like accross multiple fns, for mutually recursive calls. > All of the names are available > in all of the definitions of the functions, as well as the body. > For just single recursive function I would use recur or give the fn a name.

👍

Lol. Definitely no code... smell there. 🤢

(let [foo (atom nil)
      _   (reset! foo
           (fn[a] 
            (println a)
            (when (true? a)
             (@foo false))))]
 (@foo true))

Ya, that was just for being completionist about all options. Having a name in fn is the normal way, and letfn is the way for mutual recursion

For the sake of ease: The unresolved foo error is not by calling the function you let'd, but rather calling foo before it exists in the symbol table. To make that clearer, replace the foos with f1, f2, f3 and observe the error. The recursion in the second option works because you scoped the foo for recursion to itself.