stuff ;)

Jan 8, 2019

github.com/elwinar/rambler
phinx

this would be one thing the problem is not the up / down part where the DDL is concerned. it's the transformation parts where you cannot actually go back anymore :) Where you don't change the structure but the values.

Writing a simple migration thing is pretty easy ->

db table <migration_timestamp>_file_name

if it's SQL -> execute directly as batch if it's custom -> execute it as the language

you have up or down which can be just files to keep it simple

up.sql
down.sql

you order the files with 000 prefixes so they execute in order and this actually suffices most use cases in my experience

Usually applications don't change their SQL infrastructure and if they do they do it after 2-3 years of development and at some point some custom functions was applied to leverage the engine.

But that's just me.

TL;DR;

complete language agnostic transformations of the values can be problematic
writing a small migration software is very easy
if you never need to duplicate business-logic within the application no problem :D

my experience :) but I'm very interested if someone has a general hook system where you can hook your application into the SQL migration while still being language agnostic maybe with a small wrapper for stdin|stderr

Mark

Jan 8, 2019

Hmm yeah I tend to focus a but much on portability, it's true that most people don't change database. Though sometimes you write application logic that's sold to multiple clients that may use different databases.

Mark If it is about portability it's basically a compiler and some form of orm. or you just use the intersectional language of all SQL dialects which is hard enough.

an enum in MySQL and an enum in PSQL are quite different things for example also the behaviour of a DDL within a transaction.

in MySQL you cannot rollback a DDL in a transaction so you have to think about the behavioural patterns.

Also you cannot use the internal functions to some degree or how they apply indexes / sequences of ids.

And than don't forget internal versions the compile target, semantics, morphism you already to some degree arrive to an ORM even without using complex logics within the ORM and just keeping it a dumb query machine to encapsulate your values.

Maybe I am making it overly complex and if we isolate the problems between handling the data and creating the structure it's just a compiler who does certain transformations based on the compile target but that would need some kind of meta SQL.

maybe something like this?

but they mostly fokus on DML not DDL

Maybe applying different levels of isolation and application would help to come to better conclusion ;D I am just 'thinking out loud' :)

Search Hashnode