This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2020-10-14
Channels
- # asami (1)
- # babashka (50)
- # beginners (70)
- # bristol-clojurians (6)
- # calva (36)
- # chlorine-clover (1)
- # cider (4)
- # clj-kondo (3)
- # cljdoc (49)
- # cljsrn (5)
- # clojure (96)
- # clojure-australia (3)
- # clojure-dev (1)
- # clojure-europe (84)
- # clojure-nl (4)
- # clojure-spec (9)
- # clojure-uk (65)
- # clojurescript (31)
- # community-development (6)
- # conjure (17)
- # cursive (8)
- # datascript (5)
- # datomic (12)
- # duct (3)
- # emacs (18)
- # figwheel-main (2)
- # fulcro (7)
- # helix (1)
- # jobs (3)
- # luminus (7)
- # off-topic (77)
- # pathom (3)
- # portal (1)
- # rdf (4)
- # re-frame (1)
- # reitit (4)
- # remote-jobs (4)
- # reveal (15)
- # rum (1)
- # sci (38)
- # shadow-cljs (22)
- # spacemacs (1)
- # specter (6)
- # sql (1)
- # test-check (1)
- # tools-deps (60)
- # vim (12)
does anyone know how to interpolate a vector of ids into jdbc/update!
e.g. I want my WHERE clause to be where id in ?
and then pass in a vector
You might be able to create a connection, and create parameters for that. I had a lot of trouble with this though.
clojure.java.jdbc also uses setObject which if I recall doesn't work right with arrays even if you pass one in
@ccann HoneySQL takes care of that for you (by building the appropriate where id in (?,?,?,?,..,?)
clause given your vector of IDs.
@seancorfield I’m working on a legacy project where we only have jdbc pulled in and trying to hotfix something
If you are using PostgreSQL and next.jdbc
you might be able to do this via the array syntax -- see the PostgreSQL Tips and Tricks in the next.jdbc
docs.
But I think with clojure.java.jdbc
you're out of luck in that case.
if your vector gets too large, you'll quickly run into parameter count limits (for PG it's something like Short/MAX_VALUE
). but you can do something like below to get around that:
(j/update! db-conn :my-table ["id = ANY(?)" (into-array TheProperClass my-ids)])
@ddouglass Does that work with clojure.java.jdbc
? I know it works with next.jdbc
(that syntax is what is recommended in the next.jdbc
Tips & Tricks for PostgreSQL)
@seancorfield it does. We’re currently using clojure.java.jdbc
and that was a sanitized chunk of code from one of our apps
Nice. Thanks!
Wishing a good day to fellow Clojurians 🌱
Does anyone know a recurrence implementation in Clojure? (as defined by https://tools.ietf.org/html/rfc5545#section-3.3.10) Or maybe in Java[Script].
Thinking about a plain rule parsing / compiling for starters. They look like RRULE:FREQ=WEEKLY;UNTIL=20110701T170000Z
I’ve found http://github.com/jakubroztocil/rrule, but I hope it could be done both easier and simpler, in like 200 lines of thoughtful Clojure code.
UPD:
I’ve been advised to use spec or malli to build a parser. Can’t say yet if that’s a good idea or not.
Does anyone here recall a recent call for an upcoming virtual Clojure conference? Maybe within the past 30 days. Seems like they were asking for ~20 minute talks. I can't remember if I saw it here, on twitter, reddit, ... too many platforms.
Thanks! I tried euroclojure, clojuretre, clojureD,....
idk about you but I find (unchecked-byte (bit-and (bit-shift-right inv 8) 16rff)
way harder to read than the Java equivalent
seems like you could get pretty far with a few well chosen defs
yeah, I’ll probably whip something up but curious to see if anyone else has dealt with this before 🙂
|
, >>
, <<
are all valid function names
also why use 16rff instead of 0xff?
forgot to include 0377 above :D
@schmee an idea:
(ins)user=> (def |b unchecked-byte)
#'user/|b
(ins)user=> (def |& bit-and)
#'user/|&
(ins)user=> (def |>> bit-shift-right)
#'user/|>>
(ins)user=> (|b (|& (|>> 292928 8) 0xff))
120
actually it works without the | on every name, I didn't realize &
was a valid function name but it is
Cute… I thought that the special form would get upset with this, but it doesn’t
(def & bit-and)
(defn f [& b] (& (first b) (second b)))
=> (f 3 9)
1
right, I think this is because [& ...]
is a special case in arg list parsing rather than a special form
since it's not used in call position
though (special-symbol? '&)
does return true
I found https://github.com/rm-hull/infix, which I have seen before but it actually seems perfect for this
normally I wouldn’t consider using infix, but when I have to write pages of byte manipulation I might make an exception
having done most of my bit fiddling in assembly, I find breaking the ops into one per line more helpful than infix :D
but ymmv clearly
as a reader of code, I'd rather review a java file than infix in the middle of a clojure file
any Clojure projects out there that actually want Hacktoberfest participation?
For all practical purposes the right data structure for my problem is nested vectors. Except one thing: it needs a small piece of data attached that I want to lookup by it's key. Is it okay to put that into metadata, or should I force everything to be a map with 2 keys (data and a vector with maps of same shape)?
it might help to see an example data value, but one is the data you are considering putting in meta data actually meta data?
example:
=> {:grid [[{:grid [[{:grid [[{}
{}]]
:cursor [311708 475413]}]
[{:grid [[{}]
[{:grid [[{}
{}]]
:cursor [121699 68040]}
{:grid nil
:cursor [930988 26115]}]]
:cursor [136580 790398]}]]
:cursor [162873964 1315]}
{}]]
:cursor [42984 203305]}
the data I'm considering putting is not a meta data, it's pretty much very important data
but this structure makes lookups and updates hard, since I have to switch maps and vecs all the time, instead of doing assoc-in
/ get-in
using only coordinates
why not just make a function that looks like assoc-in
/ get-in
but works with these structures?
I just don't like it. It could be get-in
, but it has to be a separate function that interposes items with :grid
a common problem I feel like I see a lot is entangling the kind of logical structure of data with the physical structure.
one way this happens a lot is people writing games with grids try to represent the logical grid structure as a physical nesting of vectors, since that is the physical structure that most closely kind of looks like a grid
and once you treat it as a general index/lookup function you can start hanging other data in there and other indices and ways to do lookups
I concur with @U0NCTKEV8
and depending on what you are doing that might be enough, but it isn't a fully general indexing system (you can't lookup all the items in a colum or all the items in a row, etc)
I think focusing on the data type and what abstract operations it should fulfill is a good idea. you can then change the underlying implementation as needed depending on usage and performance
well, for all the uses I have nested vectors beat maps. I need to know last row. Given a row, I need to know last column. In the app there will A LOT of such data structures, so memory is also concern
but you can't hang any additional data anywhere, and you can't efficiently do inverted queries "give me all the column ids that a value bar somewhere in them"
"Except one thing: it needs a small piece of data attached that I want to lookup by it's key."
updates another place where conflating the logical structure with the physical structure makes things tricky
it is a lot easier to update a "flat" index (thing a normalized database schema) then a deeply nested tree structure
But I do have nesting, it's not a matrix NxM, it's a rows of varying length, where every item is itself a rows of varying length
that is literally the description of the logical structure of data in a graph database
Is there a way with tools.deps to list all dependencies (including transitive ones)? I want to be able to search for a specific dependency to see if it's included in my classpath?
So I noticed that a library I was using (cljs-ajax) has deprecated EDN as a HTTP request format in favor of Transit, which got me thinking: what are the downsides of using EDN over HTTP? And how is Transit better?
https://github.com/JulianBirch/cljs-ajax/issues/47#issuecomment-51251520 Couldn't find where exactly EDN is "explicitly not recommended for browser API" though.
Another bit of useful information: https://groups.google.com/g/clojure/c/9ESqyT6G5nU/m/2Ne9X6JBUh8J
alright, thanks
sounds to me like there aren’t any clear drawbacks to using EDN per se, except that there aren’t good parsers in most languages
I guess another drawback could be that there’s less tooling for e.g. routing or deep packet inspection for EDN payloads than for JSON
I think there were some other reasons. The one that I can remember is that compression is built into transit, which is nice to have.
transit is designed for wires and should definitely be preferred for that use case
in particular, it's designed to work over json and many languages (critically javascript) have very fast native json parsers. Also, it has caching built in for repeated keys etc so will generally be significantly smaller for common use cases (passing many maps with the same keys) and thus also faster.
edn is designed for places humans read and write data (like config files). transit is also designed to be more extensible in efficient ways - edn has tagged literals but they're not quite as good for crossing machine/language boundaries.
cool, thanks for the elaborate response :)