initial migration, timestamp and 32-bit machine

[sudoer]

I tried to install unmark on a Linode VM to try it out, and I had a lot of trouble getting the initial migration scripts to run. Every time, it came back with "Migrating to version 20140228091723 failed." with a little red Band Aid X.

I have never used Code Igniter before, but it seemed fairly easy to debug.

I sprinkled some log statements through the code, and I found that in Plain_Migration.php, the parent::version($target_version) was returning an empty string.

I traced this into the system migration module, and it looks like the problem is related to using the YYYYMMDDhhmmss format for the timestamp, the sscanf function that reads the numeric part of the filenames, and the fact that I am running on a 32-bit VM. It looks like PHP on a 32-bit system only allows integers up to 2^32. This 14-digit timestamp is going to use at least 45 bits, unless you treated it as a string (and that adds some other snags).

I renamed the migration file to 011_label_sort.php and I changed the migration_type to 'sequential', and it worked... at least enough to get me to the initial login / account creation screen.

I did not try this on a 64-bit web server.

I am now up against a new error, but I think it is unrelated to the initial migration.

Thanks for sharing your work, and for inadvertently exposing me to Code Igniter.

Alan

[phpfunk]

Thanks for the info. We haven't tested on any 32bit systems so this is good to know. The reason we are using this instead of sequential is because of collisions with migrations in core application with someone that has downloaded the application and is creating custom migrations.

Simple sequential iterations would/could cause collisions. Will look into some other options to try and support 32 bit systems with migration file names while still not reverting back to sequential.

Again, thanks for the info. Very much appreciated. Until we can support this I will update docs to say migrations only support 64-bit versions.

-Jeff

[sudoer]

Instead of just saying "64-bit only", give them a work-around.

I changed the application/config/migration.php to include this:
$config['migration_version'] = 11;
$config['migration_type'] = 'sequential';

And then I went to application/migrations and symlinked
ln -s 20140228091723_label_sort.php 011_label_sort.php

That was enough to get me up and running. I understand that I
might have some problems with platform upgrades later... but
this is enough to let me try the system out.

Alan

[sudoer]

I replied to the bug on github, but I am not sure if you'll get
a notice because it is already closed... so I will copy you
via email.

So far, it looks like a nice tool!

Alan

Instead of just saying "64-bit only", give them a work-around.

I changed the application/config/migration.php to include this:
$config['migration_version'] = 11;
$config['migration_type'] = 'sequential';

And then I went to application/migrations and symlinked
ln -s 20140228091723_label_sort.php 011_label_sort.php

That was enough to get me up and running. I understand that I
might have some problems with platform upgrades later... but
this is enough to let me try the system out.

Alan

On 2014-03-13 17:03, Jeff Johns wrote:

Thanks for the info. We haven't tested on any 32bit systems so this
is
good to know. The reason we are using this instead of sequential is
because of collisions with migrations in core application with
someone
that has downloaded the application and is creating custom
migrations.

Simple sequential iterations would/could cause collisions. Will look
into some other options to try and support 32 bit systems with
migration file names while still not reverting back to sequential.

Again, thanks for the info. Very much appreciated. Until we can
support this I will update docs to say migrations only support 64-bit
versions.

-Jeff

Reply to this email directly or view it on GitHub [1].

Links:

[1]
#27 (comment)

[doublehelix]

Whoops - just encountered the same issue on Windows(x64).
Even with the 64-bit version of PHP on Windows, Integers are still limited to 32-bit due to an incredibly complex (read: having to re-write the numbers core of PHP) reason.
(see: http://marc.info/?l=php-internals&m=137002754604365&w=2)

Perhaps, instead of using the yyyymmddhhmmss format, we could simply use a timestamp value (which would remain within the 32-bit range).

Regards,
James.

[phpfunk]

James,

I have thought about this as well. I have it on my docket to look at. I have to test the timestamp vs. the current format to see if it will mess anything up with current installs. Coming soon.

-Jeff

[durden]

Is there any update on this? I see it's closed, but I'm running into this issue still with the 1.2.5 release. Should I try the HEAD of master branch, the above work-around, or just wait for a new release/specific commit?

[kip9]

It should be fixed in todays release https://github.com/plainmade/unmark/releases/tag/1.5.0 - from this version on everything should work fine on 32-bit systems. Please let us know if the issue is fixed with latest release for you.

[durden]

Thanks for the update @kip9. I verified the 1.5.0 release works now on the same box that was previously failing.