What is the difference between `_draft` and `_post`?

[Tungsten78]

After reading the docs, I was under the impression that _draft would only run when running against the latest version - thinking this is where in-progress/current iteration scripts could be collected rather than requiring a version bump for every commit.

To provide more context, our database has specific ownership requirements where we need to initialize our database in 2 steps:

• First, run -a -t v0.00 -c "USER1CONNSTRING". This sets up users and roles, table creation/seeding is left to next step
• Then, `run -c "USER2CONNSTRING", to iterate all remaining versions to the latest.

Each step sees _draft be executed. This is same with _post, leading to the question of how is _draft and _post are different?

Like _init running only on the first version, we are looking for a script folder that runs only on the last version. If this is not _draft, what is the recommended way to pull this off?

[Tungsten78]

Found confirmation "Every migration run" in one of the wiki references,

_draft	Scripts in progress. Scripts that you are currently working and have not moved to specific version directory yet. Executed every time after the latest version.	Every migration run
_post	Post migration scripts. Executed every time and always the last batch to run.	Every migration run

We use _draft as described, it contains scripts not yet committed to the latest version. The expectation is that it runs on every current version migration run, but not ones in between.

[rdagumampan]

Hi @Tungsten78, thanks for reaching out and your interest in yuniql. Glad you also found these docs which its bit outdated by now as I have moved them to the official site. Nevertheless, its still accurate. The _draft is executed for every migration session/run.

The _draft and post are different in their intent. The draft is as you say to support non-version committed scripts especially when developers works on their local instance. In the absence of _draft, refactoring of scripts would be difficult as developers may have to hack the tracking table every time.

The _post is to support post migration checks. It could be that you want to write some logs to some tracking table. Cases like, you want to do integrity checks in existing tables.

[rdagumampan]

And thanks for sharing your use case. Its quite unique and makes perfect sense where you have privileged users that can setup roles and permissions and normal users who may only have DML rights.

I don't have immediate suggestion on how to best make yuniql works for your requirements. The concept of "last version" is also quite tricky because this can come from two places:

1. The latest version in the local directory
2. The version specified in the CLI parameters, if later that what's in the db tracking table

[Tungsten78]

@rdagumampan - this continues to plague us, you wouldn't happen to have a viable workaround.

We tried conditionally executing based on the target version. It doesn't appear YUNIQL_VERSION is available as token replacement so we have to query manually. Not awesome.

The only alternative is for each subsequent commit to formally bump the version which we were trying to avoid for reasons of version sprawl.

Is there an undocumented way to force the target version be re-executed? It appears currently it'll run _post and _draft only