Morning. The Spec & swagger - here’s one plan: * spec-tools is out and as stable as clojure.spec 😉 trying to get the separation of conforming & specs into clojure.spec itself - https://dev.clojure.org/jira/browse/CLJ-2116. * spec-swagger is ~70% done, we are trying to get it out before summer vacations (= in this month): first swagger2, later openapi3. Developed now as a separate repo and can be used as standalone - might end up into part of spec-tools. * ring-swagger is planned to get 1.0.0 rewrite with pluggable schema / spec / json schema / xyz, most likely after vacations * schema-tools will also get a facelift, targeting to make transition between schema & spec easy, similar way to add metadata to models, apply default values etc. some old thoughts on a gist: https://gist.github.com/ikitommi/fb3e0200504dd8b635ed7edd0cdbc768 yada-spec/swagger module should be easy as the apis are almost the same as with schema. and, everything can break with the next spec alpha..

@dominicm what does yada offer for graphql processing over just aleph ?

Hey! Is there a way to update existing resource with some additional resource model map? For example, I'd like to enrich a resource created with (as-resource "some-url") with additional :access-control info.

OK I ended up doing (deep-merge (resource my-model) (as-resource "some-url")) Hope it's idiomatic 🙂

yeah, we do it all the time 🙂

@wagjo Yes, you can merge your own config in afterwards. It would be good to call yada/resource on that for additional validation.

(@wagjo there are already examples of this in our app)

thing is yada is doing a coercion from model map to the resource map, and this coercion is not done again if you assoc into a resource later. The above deep-merge works around that quite nicely

“Since this week’s yada release manifold streams can be returned from response bodies.” I’m confused. I was previously returning a stream from a :response function with yada 1.2.4. Now I’m on 1.2.6 I find that I can’t: No implementation for render-seq for media-type: text/csv

I guess I can provide an implementation for render-seq, but this change seems to be going in an unexpected direction.

By providing an identity-like implementation for render-seq / "text/csv" it’s all working again, but I’m now wondering if I’m doing something I’m not supposed to…

@peterwestmacott sounds right. I have a feeling that something isn't being required.

as in: there some ns I should require and then this would all work by itself?

@peterwestmacott maybe, I'd consider this a bug even if that's true!

Annoyingly, I can't find the string "text/csv" in history :thinking_face:

@peterwestmacott okay, figured it out j/k

We used to throw an exception, now we return an empty string. That's all I have.

No idea how that resulted in csvs working though 🙂

Malcolm’s earlier comment about recently adding support for returning manifold streams seems to imply that I was going “off-piste” before then though.

Doesn't look like yada officially supports csvs

I've returned manifold streams before too, no idea what that commit is 😂

@peterwestmacott are you encoding the lines in the stream into a string line in the csv?

I’m putting strings onto the stream

each string contains comma separated fields

each string ends in a newline character

eg. (streams/put! stream "2017-01-01,some,data,here\n")

I see. I wonder if that change broke returning strings over a stream as being like returning a string from a response

I would think that for some media types the answer is yes

previously in yada.body/MessageBody they would have fallen through to Object, which returns the stream unaltered. Now they will have render-seq called on them which requires an implementation for the media-type

which isn’t necessarily bad, in the sense that maybe I was doing something unsupported(?), and expecting every combination of media-type/return-type to be supported out of the box is unrealistic, and it is trivially extensible

I'd like to see yada/csv 😉