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) "?" ")"))

But I don’t know where to plug my vector of ids in

@josmith2016

(j/update! db-spec :jnl {:sourcebid "whatever"} (into [(str "id IN ( " (str/join "," (repeat (count check-ids) "?")) " )")] check-ids))

use (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

more automatic than what?

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

what does the "model" notion doesn't really get reified in that way mean?

I mean, in order to derive tranforms from one model to another you need some representation of the model

e.g. a data structure that describes the database schema

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

well i guess i’ll just keep doing what i’m doing 🙂 thanks for the sanity check

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

I mean, that sounds like a cool tool, I just don't know where it would get used outside of one off web apps

thinking about, I bet you could describe your schema as a spec, then you would be diffing two specs, which I bet a lot of people would be really interested in