Clojurians Log v2

@seancorfield Thank you. 1. A level of abstraction over the database (less important, in real use I never had to swap the database). 2. I kinda like the brevity of DDL that makes it really simple rather than writing a raw SQL.. I use to write nodejs for web. I used knex , here is an example:

const tableName = 'session';

exports.up = (knex) =>
  knex.schema.createTable(tableName, (table) => {
    table.string('sid').primary().notNullable();
    table.json('sess').notNullable();
    table.timestamp('expire').notNullable();
    table.timestamp('created_at').defaultTo(knex.fn.now());
    table.timestamp('updated_at').defaultTo(knex.fn.now());
  });

exports.down = (knex) => knex.schema.dropTable(tableName);

Hmm, I find plain SQL easier to read but I can see how, with a few helper functions for common columns or column types, you could use more concise code to describe tables… and migratus does let you use code-based migrations although the format is a bit verbose. Maybe @yogthos would be open to providing a more concise version that leveraged HoneySQL to format the result of calling DDL-generating functions? Not sure what that would look like tho’… just spit-balling an idea…

I'd be open to making it easier using HoneySQL, it shouldn't be too hard to add a layer that could parse HoneySQL markup and generate SQL strings that would then be consumed. Could leverage existing edn migrations. Currently, there are :up-fn and :down-fn keys, so perhaps could have :up-honey and :down-honey that would point to HoneySQL markup.

The “benefits” would likely come from having helper functions that generated common DDL fragments so it would need to be actual code — similar to how the EDN/code migrations work today — except that the functions would produce the ["SQL"] vector that migratus would then run honey.sql/format on.

Allowing :up-fn / :up-honey / etc to be a fully-qualified symbol so the :ns could be omitted might also be nice.

And there would need to be some way to specify options for the honey.sql/format call I guess, either globally, or on a per-migration basis.

I mean, maybe there’s also an avenue for providing HoneySQL DSL as EDN but I don’t think that’s as valuable as having functions to generate the ["SQL"] vector — the DSL is pretty verbose for DDL stuff, especially table/column specs.

@yogthos IMO, Here are my two options. 1. Let people write a clj file for migration. It will be foo-123.up.clj foo-123.down.clj 2. you already have a way to run a preprocessor, I can say the default preprocessor is SQL or honeysql or tomorrow's new thing. I personally like 1. As long as I have a public method up that returns string, I can do whatever I want.

what do you guys thing?

@munichlinux The .edn version is effectively 1. It’s declarative and based on a specific function for up and another for down.

How would an arbitrary .clj file even be used? The namespace should match the filename for a start so you can’t have . in that part.

right, the current .edn version is seems very similar to option 1, it sounds like the biggest win would be in having a DSL for describing DDL fragments

@seancorfield since these files are generated. we can generate migrations.123 as the ns.

I am trying to keep this independent of edn or honeysql.

(-> (all-ns)
     (filter (starts with migrations)
      (sort by timestamp)
      (doseq [ns all-ns]
          (ns/up)))

@munichlinux The migrations need to follow a specific naming patterns so they can be run in order and all checked off in the tracking table. (right @yogthos)

Oh, are you proposing not even using migratus and writing your own custom migrations stuff?

nope, I proposing to use migratus . I was just outlining how the clj will work.

ATM, migratus can generate the file names. I propose to generate the file with an ns if we have to take the clj approach.

yeah, migratus needs to have a numeric pattern in the migration name to track the order of migrations

it might also make sense to make a separate library that leverages migratus for this

same here! i will often type out a question to the slack or to stack overflow and just typing it out to explain it often gives me more insight into the issue. First I hear of "rubber ducking" now I might have to get a comically large one for the desk...