How do you name your changes?

[lgrosz]

Hi, I have a Sqitch project. I am trying to decide how I want to name my changes before my first release, as I know once I release I cannot rename the changes. My current plan is as follows

• translate object names to kebab-case
• schemas are somewhat analogous to filesystem directories, so the schema name and / will be used as a prefix

This is generally how I prefer to organize files on my filesystem. For example, a change that does CREATE TABLE foo.bar_baz would be named foo/bar-baz.

Obviously, this creates a dirctory for foo in my deploy, revert, and verify directories. I assume that is expected considering / is implicitly called out as a valid character in the sqitchchanges guide..When it comes to adding a single column or a making some other fix (without reworking).. I am not really sure what I'd do, yet. Maybe foo/bar-baz/add-col-a?

Are there existing practices that I should follow instead? How do you do this and have you ran into any problems with your names after releasing a version?

[theory]

Your approach makes sense to me. I've sometimes use directories for separate schemas, but tables works just as well, and minimizes the chance of too many files in a single directory. :-)

The only problem I recall was too many files making it difficult to find stuff. In part to address that challenge, you can specify a separate directory for previous instances of a reworked change. See Overworked for details.

[lgrosz]

I am using separate directories for schemas. I suppose, if I had an intra-table change, then I could have a directory for the table as well. I'll definitely be moving reworked changes into their own directory when I start doing that. Regarding changes that aren't purely additions of objects, I'll just cross that bridge when I get there. Until I tag, I shouldn't encounter anything that doesn't fit what I already proposed.

I appreciate the reply!

[fluca1978]

So far, I'm using a naming scheme based on the ticket number.
I have one ticket per change, so my changes are all named with the leading number in front of it, so that I can quickly recognize what leads to where.

[lgrosz]

This would work, but I try to keep my repo content separate from my ticketing system if at all possible. Your solution seems good, just not for me personally.

[rotten]

I am organizing with separate folders, also naming create_table__mytable , and create_view__myview. This means I don't really need the comments in sqitch.plan to find the files of interest, which makes that file more readable.

I've never liked the numbering system that Django uses, so I've been avoiding numbering. sqitch.plan is sufficient for figuring out what order the migrations should be applied (for my use cases anyway).

I did not use a good naming convention, nor did I use subfolders for previous projects with sqitch and it quickly became a mess and really hard to figure out what was going on. I think organizing from the beginning is super helpful in the long run.