cch1

(let [undefined-value (atom :undefined-value)] 
 (defn pick-and-rename [col pick-map]
  (apply assoc
         {}
         (flatten
          (filter (fn [[k v]]
                    (not (= v undefined-value)))
           (map (fn [[k v]]
                  [v (get col k undefined-value)])
                pick-map))))))

cch1

(ns test-helpers
  (:import [java.io InputStream OutputStream IOException])
  (:require [clojure.java.io :as io]))

(defn- swap-!
  "Atomically swaps the value of atom to be:
  (apply f current-value-of-atom args). Note that f may be called
  multiple times, and thus should be free of side effects.  Returns
  the value prior to the update."
  [a f & args]

cch1

(ns template
  (:require [clojure.edn :as edn]
            [clojure.string :as string]))

;; Tagged literals do not need to be limited to being represented by a single string.  Here we represent a value with a tuple of `magic` and `value`.
(defn read-magic [[magic value]]
  (case magic
    :c (string/capitalize value)
    :l (string/lower-case value)
    :u (string/upper-case value)))

cch1

I realize this is going to seem heretical, but here goes: there is value in ensuring schema as part of instance startup.  At Sun Tribe, we've been doing it for years.

The biggest advantage is the ease of binding the schema to the code.  When combined with a testing strategy that stands up an in-memory database from scratch (many times, in fact, while running the test suite), it's easy to guarantee that the schema and code are exactly that which will be eventually ensured and run in production.  It's also easy to travel back in time locally (schema and code) by starting the system on a previous commit, sometimes making forensics a little easier.

I realize there are limitations with this approach.  For example, long-running data corrections need to be carefully considered lest they block system startup for "too long".  It's also important to have lifecycle hooks that can declare a startup failure and roll back a deploy (cough, cough... Datomic Ions).  Otherwise a schema mismatch (really only possible if someo

cch1

I realize this is going to seem heretical, but here goes: there is value in ensuring schema as part of instance startup. At Sun Tribe, we've been doing it for years.

The biggest advantage is the ease of binding the schema to the code. When combined with a testing strategy that stands up an in-memory database from scratch (many times, in fact, while running the test suite), it's easy to guarantee that the schema and code are exactly that which will be eventually ensured and run in production. It's also easy to travel back in time locally (schema and code) by starting the system on a previous commit, sometimes making forensics a little easier.

I realize there are limitations with this approach. For example, long-running data corrections need to be carefully considered lest they block system startup for "too long". It's also important to have lifecycle hooks that can declare a startup failure and roll back a deploy (cough, cough... Datomic Ions). Otherwise a schema mismatch (really only possible if someo