Parameters in JDBC Migration

[xsc]

Using the EDN-based JDBC migrations – which I'm trying to create on-the-fly from a non-SQL specification – I'd like to do the following:

{:id "something"
 :up [["INSERT INTO table (column) VALUES (?)" "value"]
      ...]
 ...}

ragtime.jdbc/execute-sql! currently can't handle this. This could be added in a completely backwards-compatible manner and I'd be happy to supply a patch if desired.

[weavejester]

Could you tell me a little more about your use-case? At first glance this seems fine, but I'd like to know a little more about what circumstances this is used for. It seems like it's quite a niche bit of functionality.

[xsc]

Sure. In my case, I know that a few very similar migrations will be coming up repeatedly in the future. So, to make the chore a bit more bearable, I'm programatically generating them from a declarative input format that looks similar to the following:

{:add-relationships
 {"a" "b"
  "b" "c"}
 :remove-relationships
 {"g" "h"}}

My program then produces a migration akin to:

(ragtime.jdbc/sql-migration
  {:id "some-id"
   :up [["INSERT INTO relationships (from, to) VALUES (?, ?)" "a" "b"]
        ["INSERT INTO relationships (from, to) VALUES (?, ?)" "b" "c"]
        ["DELETE FROM relationships WHERE from = ? AND to = ?" "g" "h"]]
   :down [["DELETE FROM relationships WHERE from = ? AND to = ?" "a" "b"]
          ["DELETE FROM relationships WHERE from = ? AND to = ?" "b" "c"]
          ["INSERT INTO relationships (from, to) VALUES (?, ?)" "g" "h"]]})

Of course, one could argue the use case (which is more data management than database management), but allowing use of SQL query vectors has the following advantages for me:

• I can store the full, ?-parameterised query string in a variable and do vector- instead of string-concatenation.
• I don't risk producing invalid SQL from unescaped string values in my input map.
• I don't have escaped string values in the input map, making it oh-so-slightly harder to process by humans.

The latter two apply to the already existing EDN JDBC migrations, as well, IMO.