This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2018-03-01
Channels
- # aleph (4)
- # arachne (24)
- # beginners (231)
- # boot (4)
- # cider (63)
- # clara (36)
- # cljs-dev (57)
- # clojure (195)
- # clojure-dev (12)
- # clojure-gamedev (2)
- # clojure-greece (1)
- # clojure-italy (10)
- # clojure-poland (4)
- # clojure-spec (36)
- # clojure-uk (65)
- # clojurescript (133)
- # core-async (8)
- # core-logic (2)
- # cursive (18)
- # data-science (3)
- # datomic (58)
- # defnpodcast (3)
- # duct (2)
- # emacs (2)
- # fulcro (27)
- # graphql (3)
- # hoplon (18)
- # jobs (2)
- # jobs-discuss (10)
- # jobs-rus (1)
- # lumo (1)
- # mount (6)
- # nyc (2)
- # off-topic (27)
- # pedestal (13)
- # re-frame (71)
- # reagent (105)
- # reitit (4)
- # ring (2)
- # ring-swagger (1)
- # rum (10)
- # shadow-cljs (172)
- # spacemacs (24)
- # sql (26)
- # tools-deps (1)
- # uncomplicate (4)
- # unrepl (51)
- # vim (3)
- # yada (11)
Can I run a bulk update similar to that bulk select up there @seancorfield? something like this?
(j/update! db-spec :jnl {:sourcebid } ["id IN(" (repeat (count check-ids) "?" ")"))
(j/update! db-spec :jnl {:sourcebid "whatever"} (into [(str "id IN ( " (str/join "," (repeat (count check-ids) "?")) " )")] check-ids))
that should do ituse (into [ sql-statement ] params)
to "pour" your parameters into that vector that contains your SQL statement
use (str "sql fragment" computed-str "more sql")
to build the string dynamically
str/join
assumes you have [clojure.string :as str]
in your :require
clause -- it's such a common alias that many people will offer code fragments with str/
in them, assuming you know that alias
(and I'm assuming here you want to set :sourcebid
to a fixed value for all of those check IDs -- one update for many keys)
Thanks @seancorfield
i just poked through half a dozen sql libraries. curious: is there anything out there that makes migrations more automatic? i’m constantly surprised this problem isn’t solved
i mean can i just specify a model in one place, then ask for it to generate a migration from the current state of affairs, instead of me writing a bunch of up/down code
my guess would be the "model" notion doesn't really get reified in that way (like in rails or what have you) in most clojure apps
it seems like such a lisp with all of its metaprogramming kung fu would be really well suited to this. maybe people use datomic? this isn’t solved in javascript either, which also surprises me. its super painful and error prone
I mean, in order to derive tranforms from one model to another you need some representation of the model
most clojure code I have worked on (and my experience is mostly outside of the realm of consumer facing web apps, but my current job is kind of that, but I am pretty firmly on the backend), just does sql stuff either via sql strings or something like hugsql
this job and my last one both have had sort of home grown migration frameworks that largely consisted of files containing sql to run to migrate
I do sort of database reflective things from time to time, but I don't do them by manipulating some model of the database in my program, I have my program connect to the database as ask it to describe itself (what tables are there, what are the types of the columns, etc)
yea exactly. wouldn’t it be awesome to have a description of what you want your database to be and then have a program that does a diff? even if it required you to restrict your model, that’d be so convenient. in js, tools like sequelize can already turn a js-based description of a model into accurate DDL, including doing foreign keys, indexes, and so forth. but once you want to move to migrations you have to rewrite all the junk by hand. it’ll automate the part where it remembers what migration you are up to and will apply the patches in the right order, but you still have to write them yourself
it depends what you are comfortable with, if you are comfortable with sql, then sql files containing ddl are exactly what you are describing
hm maybe i don’t follow. for the initial database construction, that’s true. but where a tool could be useful is in crafting the delta between the state of the database and the state of your model. i.e., adding a column or a relation. it would be much nice to just edit your model and then have a tool craft the migration.
if you are comfortable with sql, then the sql ddl is exactly that description of how to change things to get what you want