This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2016-01-24
Channels
- # aatree (27)
- # admin-announcements (5)
- # all-the-channels (2)
- # aws (27)
- # beginners (38)
- # boot (48)
- # braid-chat (18)
- # cider (6)
- # cljs-dev (9)
- # cljsrn (8)
- # clojars (4)
- # clojure (73)
- # clojure-dev (2)
- # clojure-russia (2)
- # clojure-sg (1)
- # clojurescript (96)
- # code-reviews (3)
- # community-development (4)
- # conf-proposals (17)
- # core-matrix (2)
- # cursive (2)
- # datascript (4)
- # datomic (4)
- # dirac (1)
- # funcool (5)
- # hoplon (2)
- # mount (66)
- # off-topic (35)
- # om (211)
- # parinfer (2)
- # pedestal (2)
- # proton (1)
- # reagent (2)
well yada is built on aleph, and catacumba seems to aim higher (meaning it's not low-level)
well there is a lot of docs for catacumba so I may just have a look - although I am pretty much commited to yada by now
@nha the big difference between catacumba and yada, is that yada is very opinionated in terms on how the things should be done and catacumba is much les opinionated.
catacumba is much like aleph but a little bit more high level and web development focused
Ok I see. I was looking through the docs assoc-routes!
seemed opinionated to me when first reading it
assoc-routes is part of the "component" integration, but it does not uses any strange magic, you can do it yourself
and it is not mandatory to use that, it is named toolkit because it offers different things but them almost all are optional
and you can use just that you want or just reimplement them, catacumba is entirelly open to extensibility
maybe a crazy question - would it be possible to mix them in a project (meaning on the same server component) ?
Yes, this is the difference, catacumba has a ring handler adapter (you can put a ring handlers under some route)
but in the ground it works a little bit different and it is not constrained to ring spec
ring is designed for synchronous operations, and catacumba approach with route pipeline of handlers is designed from the ground up for async
Right I saw that somewhere already. With the pedestal guys I think. So catacumba is more integrated as well (meaning has the routing part built-in).
With ring is designed for synchrnous apps I mean that all middleware stuf build on ring does not works well in async environments
in fact is not a routing, is just a pipeline of handlers that can take decisions on the flow
boring Sunday? looking for a project? write a library to print Clojure data structures into Chrome DevTools Console: https://github.com/binaryage/cljs-devtools/issues/11
can anyone give me a quick rundown on testing frameworks in clojure? Is there a defacto leader?
looks like there is clojure.test, Speclj and something called Midje. Do most people just use clojure.test?
We use Expectations very heavily.
I suspect clojure.test is popular because it's built in but it's pretty basic assert-style stuff.
There's test.check in contrib for generative testing (which can be really useful in many cases).
We found Midje had too much "magic" for our tastes and requires learning a whole new DSL that didn't feel very Clojure-y (to us). We liked the minimal style of Expectations and we like the way it has evolved over the years.
We use test.check a little too (with Expectations).
I'm use speclj. BDD style, looks nice. Try midje, but don't found how to execute action before each test (resetting DB) and return to speclj. It's old, seems that not maintained. but works.
We use clojure.test with clj-webdriver because it suits the procedural "assertive" nature of WebDriver.
@intey: interesting... I looked at Speclj but the lack of maintenance put us off.
If you use Boot, there's a task for Expectations now (as well as one for clojure.test).
Yeah, it's looks abandoned. But tests looks pretty with it. Maybe in biggrer projects it isn't so.
So this is a little bit off-topic, but maybe someone knows—I was using YeSQL, which reads SQL-format files into JDBC parameterized queries. It's been fine! But evidently, you can't parameterize ORDER BY
or sort direction (`ASC` / DESC
) in a JDBC PreparedStatement, at least with Postgres.
This seems like a really common need. If anyone has run into it, and has a better idea than "just build all your queries from strings, losing all the benefits of parameterized queries in the first place", I'm all ears.
...although the more I read about it, the more I realize that ORDER BY
and sort direction are simply outside the purpose of prepared statements... weird that LIMIT
and OFFSET
work, though.
Postgres has a CASE
statement that could do what you're talking about; I think you could inject a true
. I'll try that!
I don't think you can parameterize the field to order by, though: it's a raw table identifier in SQL, not a field value.
Even if the sort direction can be parameterized using your suggestion, that would be really nice. But I'd still need user/get-users-ordered-by-foo {:page 2, :per-page 100, :sort :asc}
instead of user/get-users {:page 2, :per-page 100, :order-by :foo, :sort :asc}
.
I really don't want to get into the business of building queries from strings in my own code, though. That's way too 2001 PHP for my taste.
CASE WHEN <condition> THEN <result> [WHEN <condition> THEN <result> ...] ELSE <fallback>
So, ORDER BY foo CASE WHEN :asc THEN ASC ELSE DESC
... maybe? I haven't used it, but I saw a co-worker use it recently, and it was like that. Kind of an unexpected detour in the SQL syntax, but I get it.
@amacdougall: HoneySQL works well for building queries dynamically
Ah, thanks for the recommendation! I'll look at it. I'm considering all possibilities right now. It's a real shame, though—I really like YeSQL's core concept, and it obviously makes it really easy to write whatever SQL you feel like. But of course, it's not like it's difficult to test some SQL in the db console and then throw it in a string once it's cooked... see every SQL heredoc ever written.
there should be a way :) If sort direction is the only limitation maybe create two views that differs only by sort direction?
Well, in theory I'd want my admin page to have a sort direction toggle for every field—that's pretty standard. But that means I'd have to have an easy way to specify every combination of order-by and sort direction. YeSQL wants to generate a Clojure function for each SQL query, which makes sense as long as... huh. I guess I could write some monster query which has an internal CASE
statement which turns on a string passed into it...
SELECT * FROM USERS
CASE order_by
WHEN "email" THEN ORDER BY email
WHEN "username" THEN ORDER BY username
CASE sort_direction
WHEN "asc" THEN ASC
ELSE DESC;
But that would require setting the values of order_by
and sort_direction
based on query parameters, and man, I just don't want to get into it.
Not to mention that I'd need a WHEN .. THEN
clause for every field I want to be able to sort on.
I'll try HoneySQL first. I'll just have to unravel some of the Luminus defaults.
Actually, the hell with it; I'll just make a distinct and awkwardly-named query/function for each combination of stuff, by copy-pasting shamelessly, and then I'll wallpaper over it in my user/get-users
function.
(defn get-users [params]
(let [f (case (:order-by params)
:username db/get-users-ordered-by-username
:email db/get-users-ordered-by-email)]
(f params)))
It's going to be gross, but it will let me forge ahead without any further analysis paralysis.