Add absolute path to Spiral/Database/Injection/Fragment in alterColumn function

[mrakolice]

Without leading slash composer try to find this class in Migration namespace instead of global.

[mrakolice]

I found monkey patching solution for this particular usecase, spiral/reactor/src/Serializer#117-119 need to be rewrite as

 if (is_object($value)) {
            return '\\' . var_export($value, true);
}

[mrakolice]

Or just add __set_state function to Spiral/Database/Injection/Fragment class

[wolfy-j]

Thank you for the report. Will be fixed today.

[wolfy-j]

Please check the v2.7.1 version of spiral/database. Let me know if you still need the Reactor change.

[mrakolice]

This problem is still in project. So I think, that Reactor need to change a little bit.

[wolfy-j]

I would greatly appreciate your PR to Reactor. If not I’ll check next week.

[vvval]

At least it would be great to have a failing test

[mrakolice]

Here example of failing entities.

https://github.com/mrakolice/migrations/tree/error-with-spiral-reactor

my composer.lock:

cycle/orm v1.1.18
spiral/database v2.6.10
spiral/reactor v2.2.2

[mrakolice]

If I try to do

if (is_object($value) && method_exists($value, '__set_state')) {
            return '\\' . var_export($value, true);
}

in spiral/reactor/Serializer.php, then function BaseTest->assertSameAsInDb start working unexpectedly

But in database I can see changes (column type change from integer to bigint)

[vvval]

@wolfy-j I assume that the second error in tests is related directly to the migrations package

[vvval]

The reactor has been fixed in the v2.2.3 release

[mrakolice]

The reactor has been fixed in the v2.2.3 release

Thanks! I am waiting for migrations package fix.

[vvval]

@mrakolice I've added your breaking input as a PR to the cycle/migrations itself

[vvval]

By the way, what is the purpose of changing PK column type? Also, I assume that the correct alter change should contain also primary=true annotation attribute

[mrakolice]

@vvval yeah, you absolutely right about primary=true, but this solution works only with fresh database, created with CodeFirst. This problem (with sequences) starts when you try to migrate from existing schema, in my case created by another orm(eloquent).

I think, this problem will be exist when altering fields with other sequences, rather than PK, but I don't testing it.

[wolfy-j]

Val, can you check the default value of that column and see what needs to be written into Column in order to keep the type persistent.

[wolfy-j]

Would readonly schema help in this case?

[vvval]

@mrakolice see above please

[mrakolice]

What should I do? Make database schema (in rdbms) readonly or what?

[wolfy-j]

Check readonlySchema annotation, it won’t generate migration for your table: https://cycle-orm.dev/docs/annotated-entity

[mrakolice]

This is not my solution, unfortunately.