binaryuuid wrongly seen as binary in tests

[dereuromark]

Description

When opening the browser, all seems well for a uuid table defined in migrations as

->addColumn('uuid', 'binaryuuid', [
		'default' => null,
		'limit' => null,
		'null' => false,
	])

and correctly in DB as binary(16)

When running tests however, on find() the resource is written directly into the entity field as such (not as converted strings), making the tests fail.

object(Sandbox\Model\Entity\ExposedUser) id:0 {
  'id' => (int) 1
  'name' => 'Foo Bar'
  'uuid' => (resource (stream)) Resource id cakephp/cakephp#2823

The reason seems to be that the type of that column is suddenly binary only, in tests.
So the BinaryUuidType::toPhp() is never invoked, of course.

dd(TableRegistry::getTableLocator()->get('Sandbox.ExposedUsers')->getSchema()->getColumn('uuid'));

[
  'type' => 'binary',
  'length' => null,
  'null' => false,
  'default' => null,
  'precision' => null,
  'comment' => null
]

This seems to be a regression coming from 4.x where this worked (and tests were green)

Note: This seems to happen with any type of DB, Mysql/Sqlite...
Refs https://github.com/dereuromark/cakephp-sandbox/actions/runs/6806484697/job/18507784939#step:10:384

The only difference is that in 4.x I used the fixture structure directly, with 5.x I was now forced to move to Migrator run.

CakePHP Version

5.x

PHP Version

8.2

[markstory]

Is the schema being generated by your migration different than the fixture schema?

[dereuromark]

No
https://github.com/dereuromark/cakephp-sandbox/blob/4.x/plugins/Sandbox/tests/Fixture/ExposedUsersFixture.php#L21
and now only

->addColumn('uuid', 'binaryuuid', [
				'default' => null,
				'limit' => null,
				'null' => false,
			])

for both actual DB and test setup.

Is it possible to see the results? As the DB is resetting after each test right now.

[dereuromark]

This branch/PR showcases it in real life example: dereuromark/cakephp-sandbox#66
Only failing issues remaining is this regression on the binaryuuid type (compared to green 4.x).

Also:
bin/cake bake migration_snapshot produces the correct 'binaryuuid' type, so the issue must be specific to the test harness around running the migrator.

[markstory]

Is it possible to see the results? As the DB is resetting after each test right now.

You could dump the generated schema out of the database server.

I'm guessing that the column types we're generating aren't being picked up by schema reflection as binaryuuid.

[markstory]

Looking at the schema your currently generating through migrations I see

CREATE TABLE `exposed_users` (`id` INTEGER NOT NULL PRIMARY KEY AUTOINCREMENT, `name` VARCHAR(100) NOT NULL, `uuid` BINARY_BLOB NOT NULL, `created` DATETIME_TEXT NOT NULL, `modified` DATETIME_TEXT NOT NULL);

Which does not qualify as binaryuuid because the length is wrong. It looks like phinx/migrations is currently generating BINARY_BLOB for the binaryuuid type which doesn't seem correct.

The root cause of this issue is that phinx currently maps binaryuuid to the BINARY_BLOB type which will never be counted as binaryuuid by cakephp because we only accept binary(16).

If we cannot make this change in phinx because of backwards compatibility, then this is more fuel under the fire for cakephp/migrations#647 so that we can make the change in migrations.

I know you're not a fan of having to use migrations for test schema. Would having the abstract format that we use for cakephp exposed as a public interface be a better solution for you?

[dereuromark]

Sounds like a bugfix for phinx, since this doesn't seem to be fully working.

[dereuromark]

Or we shim it in migrations plugin

[dereuromark]

Yeah, so turns out that
cakephp/phinx#1734
was the problem all along, it probably should be a different type than this.

But cakephp/phinx#2239 doesnt quite fix it either yet