Added TimestampedMigrationAttribute

[ericburcham]

Great job with fluentmigrator. We love it around here!

I added a class, TimestampedMigrationAttribute, which extends MigrationAttibute. This class derives the underlying "Version" value from the given year, month, day of month, hour, minute, and (optionally) second. It also provides constructors that accept TransactionBehaviour and Description, so it provides the same instantiation options as the base type.

We're using something similar on a huge project to limit the amount of effort we put into "claiming" the next ordered migration. We just create a TimestampedMigration instead, and only worry about conflicts when migrations created by different people actually conflict with one another.

[tommarien]

@ericburcham What is wrong with just taking a yyyymmddhhmmss approach ?

[bryansray]

@tommarien Nothing particularly wrong with it aside from "it's a bit brittle."

We needed to provide a bit more "dummy proof" way to ensure that our development team got their migrations created in the correct format. Disseminating the timestamp format and enforcing it were at the top of our priority for the current environment.

[ericburcham]

Well… at a glance, nothing.

When you live with it for a while, some things might come up. For example, that approach assumes:

1.  You don’t care about invalid dates / times.  We do.
   

2.  You find that 20141111075613 is easy to visually parse.  Almost nobody does, though this is pretty easy:  2014, 11, 11, 07, 56, 13
   

3.  You can easily train the N people on your team to all format their dates the same way.  We have 60+ people from lots of different cultures, so that is a challenge for us.  But auto-complete gives constructor hints:  year, then month, then day, etc…
   

It isn’t a hugely important thing, but it was important enough to us to spend a little time working on it.

[tommarien]

Maybe i did not make myself clear enough, smartphone reacting has that effect ;). I am all up for a more sturdy approach to enforcing team to use the same versioning manner, but i was just wondering why the complex calculation to ticks was necessary in the implementation. You could have just gone for the timestamp to number approach.

[ericburcham]

Got it!

Using ticks pads the right side of the version value with several additional decimal places in case we want to insert finer resolution, versioning, or some other mechanism later. This way we can do so without New migrations after such a change automatically getting much larger versions then exist for any previous migrations.

I know you should never really rewrite history, but for us this is of occasional concern.

The conversion of a date and time to ticks comes straight from the internals of the DateTime type, so it wasn't really very complicated to do.

Sent from my iPhone

On Nov 12, 2014, at 1:30 AM, Tom Marien <notifications@github.commailto:notifications@github.com> wrote:

Maybe i did not make myself clear enough, smartphone reacting has that effect ;). I am all up for a more sturdy approach to enforcing team to use the same versioning manner, but i was just wondering why the complex calculation to ticks was necessary in the implementation. You could have just gone for the timestamp to number approach.

Reply to this email directly or view it on GitHubhttps://github.com//pull/537#issuecomment-62680310.

[ericburcham]

Did you have any more questions about this one? I'm not married to the DateTimeToTicks implementation. If you prefer, I can update it to your yyyymmddhhmmss approach. Let me know.

[tommarien]

The simplier the better ;)

[ericburcham]

I'll be updating this tonight. The resulting long will be in the following format:
yyyyMMddhhmmss

After it casts to a long, any year less than 1000 will have be shortened to one, two, or three digits, of course, since you cannot pad a long with zeros. The rest of the values will always be two digits so that reading the intended date/time during migration output will be as easy as possible.

[ericburcham]

I have updated TimestampedMigrationAttribute to use the format yyyyMMddhhmmss.

The date and time are still validated on construction, and test coverage is still 100%.

[tommarien]

@ericburcham Thanks for this simplified feature, great work !

[ericburcham]

@tommarien - My pleasure :)