initial migration, timestamp and 32-bit machine about unmark HOT 8 CLOSED

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

from unmark.

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

from unmark.

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)

from unmark.

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.

from unmark.

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

from unmark.

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?

from unmark.

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.

from unmark.

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

from unmark.