Add support for non-incremental (or long) migration versions

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Assume your trunk has migrations through #13
2. Create a new branch of your project
3. Users on either trunk or the new branch may create migration #14
4. Merge branches.  Now there's duplicated numbers and a bunch of work to
resolve.

This is really an architectural decision more than a bug, but other
projects have already worked around this problem by using timestamps
instead of sequence number.  If the migrator.net team already has ideas in
process on this please ignore this bug.

I'd like to use timestamps of the form 'yyyymmddhhmmss' for my project -
that would require MigrationAttribute to use a long instead of an int. 
What are the chances of getting this in place as a quick fix?  I'd be happy
to work on and contribute a patch (it would be pretty tiny, I think) if
this is an acceptable decision.

Original issue reported on code.google.com by spamguz...@gmail.com on 21 Jul 2008 at 6:10

[GoogleCodeExporter]

If the only change for this to work would be to migrationattribute class then 
if you 
supply a patch I will apply it asap.

there may be a change required in the generation of the SchemaVersion table 
which 
holds the current migration number of the database.

If you can supply a patch along with any test changes that may be required I 
will 
look at it and then apply it to the trunk.

Thanks

Sean

Original comment by dko...@gmail.com on 21 Jul 2008 at 10:25

[GoogleCodeExporter]

As it turns out, version numbers are in lots of files (loggers, 
transformations, etc)
so my patch will touch quite a few files.  Also, given my use case, the 
behavior of
"up" and "down" to simply start at 1 and increment by one to get next and 
previous
doesn't work - it would have to count to 200 billion before finding the first 
item. 
I'll have to think about how to fix that.

I also changed the Categories of a few unit tests to be more consistent (there 
were
both "Postgre" and "PostGreSQL" categories, for example) since I didn't see why 
I'd
need to say twice to exclude those tests (I don't have postgres).  Attached is 
that
patch.  Should I open another issue for it and attach it there instead?  
Forgive my
lack of etiquette knowledge - this is my first time contributing to a project. 
:)

Original comment by spamguz...@gmail.com on 22 Jul 2008 at 1:27

Attachments:

• test-categories-cleanup.patch

[GoogleCodeExporter]

I think using dates as the migration number will cause more problems then it 
solves.
If you have big gaps between migration numbers because of when they are 
created, you
will never know if a migration has been performed on a database like you can do 
for
numbers that increment by 1 each time. You will also find that when you merge
migrations that have numbers that fit in between others you already have on your
current branch, these won't get run because the DB only stores the current 
schema
version not a list of the migrations run.

You could change the migration attribute so it has a datetime overload and 
somehow
enable another mode of migrations where it records the migrations that have 
been run
in the DB. A GUID might work better than a datetime for this type of migration 
where
you just need to uniquely identify it, then you could specify what previous 
migration
this one depends on with another GUID.

Original comment by jono%jon...@gtempaccount.com on 22 Jul 2008 at 3:05

[GoogleCodeExporter]

I think Jon may be correct here.

It would have to be an overload on the attribute so we can attach the migration 
number, and datetime to that particular migration.

I am going to label this as an enhancement. If anyone wants to pursue it 
further, 
please provide a patch for the new migration numbering behavior and we will be 
happy 
to take a look at it.

As far as the categories fixes, I will apply those tomorrow. Thank you for the 
patch!

Don't let this deter you spamguzzle. If you would like to contribute more, 
simply 
attack any ticket on the issue list. I haven't had much time lately to 
contribute to 
migrator, so any help is greatly appreciated!

thanks

sean

Original comment by dko...@gmail.com on 22 Jul 2008 at 3:13

• Added labels: Priority-Low, Type-Enhancement
• Removed labels: Priority-Medium, Type-Defect

[GoogleCodeExporter]

>the DB only stores the current schema version not a list of the migrations run.

Yes, that's another issue I'd have to address.  Storing the list of migrations 
would
be the only way to resolve the branches (I think this is the way the latest 
Rails
stuff works?) but changing that might be a bit more ambitious than I am 
prepared to
deal with at the moment.

So.. we can either switch the numbering to longs now in case I (or someone) 
decides
to implement list-of-migrations storage, or perhaps this bug should be 
invalidated
and/or decided to be incompatible with the current project goals.  I leave it 
to an
administrator to decide.  Attached is where I wound up with the longs patch.

Original comment by spamguz...@gmail.com on 22 Jul 2008 at 3:17

Attachments:

• long-versions.patch

[GoogleCodeExporter]

This really might need to be an all or nothing change probably. The timestamp 
replaces the incrementing 
number. The schema_version table the stores the timestamps of all of the 
migrations that have been applied as 
opposed to just the last one.

This fix is really the only way that you can support developing on branches.

This is the direction that migrations in Rails has gone. We could look at that 
implementation a bit closer to 
figure out any details.

Original comment by geoffl...@gmail.com on 22 Jul 2008 at 3:18

[GoogleCodeExporter]

Oops, I think I missed the test file in that patch.  Here's a replacement patch 
to
fix it.

Original comment by spamguz...@gmail.com on 22 Jul 2008 at 3:39

Attachments:

• long-versions.v2.patch

[GoogleCodeExporter]

ok, can anyone else see any problems with changing the int migration numbers to 
long 
datatype?

if not, i will go ahead and apply this patch. speak now or forever hold your 
peace =)

Original comment by dko...@gmail.com on 22 Jul 2008 at 7:40

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Oh, that patch is based on v101 code (sans the long change).  I'll have to 
update it
if dkode8 commits the other patch. :P

Original comment by spamguz...@gmail.com on 22 Jul 2008 at 11:20

[GoogleCodeExporter]

ok, lets try this real quick. can you first post the int-to-long.patch and name 
it 
just like that.

What was the other patch you were referring to?

Original comment by dko...@gmail.com on 23 Jul 2008 at 12:57

[GoogleCodeExporter]

Here's the int-to-long patch again.

The "other" patch mentioned in comment 10 is the patch from comment 9 - a
preliminary, incomplete attempt at changing the Migrator to use non-sequential
numbers and lists of applied patches instead of a single sequence of ints.  It 
is not
yet ready for production but I thought one of y'all might want to look at the
direction I'm going.  Too many patches on one bug I guess.  Maybe the 
non-sequential
stuff should be broken out to another bug?

Original comment by spamguz...@gmail.com on 23 Jul 2008 at 4:00

Attachments:

• int-to-long.patch

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Non-sequential versioning has been broken out into Issue 47.  I removed my 
comments
regarding that change from this bug for cleanliness.

Original comment by spamguz...@gmail.com on 26 Jul 2008 at 3:45

[GoogleCodeExporter]

With commit 103 I think this bug can be closed.  The non-sequential stuff is 
now in
issue 47.

Original comment by evon...@gmail.com on 1 Aug 2008 at 1:29

[GoogleCodeExporter]

Int to long done, so I'm closing this as fixed.

Original comment by geoffl...@gmail.com on 4 Aug 2008 at 2:16

• Changed state: Fixed
• Added labels: Milestone-8