\Expose\Converter\Short: Support UUID v7

[asgraf]

Here is test code:

$uuidOrginal = \Ramsey\Uuid\Uuid::uuid7()->toString();
$uuidShort = \Expose\Converter\ConverterFactory::getConverter()->encode($uuidOrginal);
$uuidDecoded = \Expose\Converter\ConverterFactory::getConverter()->decode($uuidShort);
debug($uuidOrginal === $uuidDecoded);

debug is returning false when default \Expose\Converter\Short is used

Changing to \Expose\Converter\KeikoShort by adding line below makes debug returns true as expected

//in config
'Expose.converter' => \Expose\Converter\KeikoShort::class,

[dereuromark]

Yeah I dont know what the issue is, but I documented it for now. See PR.
If someone finds a way to fix it up, that would be awesome.

[dereuromark]

It seems UUID7 is in general not working properly? https://github.com/dereuromark/cakephp-expose/actions/runs/6038051495/job/16383565370?pr=16

[asgraf]

The issue is that the strings are shifted

'018a4bd3-0218-727e-ad08-33ac76dd1593' <-uuidOrginal
'18a4bd30-2187-27ea-d083-3ac76dd15930' <-uuidDecoded

uuidOrginal has leading zero
uuidDecoded has trailing zero

[asgraf]

Look at those two strings without dashes:

018a4bd30218727ead0833ac76dd1593
 18a4bd30218727ead0833ac76dd15930

if you ignore the hyphens and those two zeros then both strings are identical

[dereuromark]

I documented the issue now, see merged PR, I will keep this open for now, maybe someone has an idea for support.
I wonder if a separated issue should be made for keiko converter, as they might face a similar issue there ( https://github.com/mgrajcarek/uuid-shortener/issues ) from the test cases that prove it also fails for them.
Maybe double check before posting there if their native converter doesnt support yet v7 either.

[asgraf]

I don't think this has anything to do with v7 but with leading zeros.
Any uuid with leading zeros would be problematic
Uuid v7 just happens to have unix timestamp encoded in leading bytes and we are many years away to have non zero value in first byte
Other uuid types that have random bytes in leading bytes just have low probability to have leading zero (1 in 16)

[dereuromark]

Yeah, but it is weird that both converters have this issue, not aware of this problem

[dereuromark]

At least in the tests, how did u make Keiko work?

[asgraf]

At least in the tests, how did u make Keiko work?

You are just testing wrong converter in your test
You should replace ConverterFactory::getConverter() with $this->converter in KeikoShortTest.php and ShortTest.php

ConverterFactory::getConverter() returns whatever converter you have defined in your config file instead of the one you want to test

[dereuromark]

Copy and paste^^ thx, will fix laters

[asgraf]

As i expected source of problem are leading zeros

$uuidOrginal = '00000000-1111-2222-3333-444444444444';
$uuidShort = \Expose\Converter\ConverterFactory::getConverter()->encode($uuidOrginal);
$uuidDecoded = \Expose\Converter\ConverterFactory::getConverter()->decode($uuidShort);
debug($uuidDecoded);
//  \Expose\Converter\Short outputs: 11112222-3333-4444-4444-444400000000

I think this happens because you are converting hex string to hex number and converting numeric string to number always drops leading zeroes (base 16 does not matter). So you are going from 00000000111122223333444444444444 string to 111122223333444444444444 number
And then you convert this number back to fixed length string that results in extra trailing zeroes