$uuid->getBytes() returns different value after database roundtrip with uuid_ordered_time about uuid-doctrine HOT 5 CLOSED

You're right. The test fails:

1) Ramsey\Uuid\Doctrine\UuidBinaryOrderedTimeTypeTest::testGettersReturnSameValuesAfterDatabaseRoundtrip
Failed asserting that two strings are equal.
--- Expected
+++ Actual
@@ @@
-Binary String: 0xff6f8cb0c57d11e19b210800200c9a66
+Binary String: 0x11e1c57dff6f8cb09b210800200c9a66

I know it seems awkward, but this is how the OrderedTimeCodec works.

When it decodes the bytes, it puts them back into the order specified by the RFC, but when you get the bytes (using getBytes()) to put them into a database, it returns the bytes in the "ordered time" order, which rearranges the time fields, so that it can be stored in such a way that the table can be sorted by the UUIDs, and they'll be sorted in the order in which they were created.

What's happening in the test you've provided is that Uuid::fromString() is creating a standard Uuid object. There's nothing special about it. So, when you call getBytes(), they're in the proper order, as defined by the RFC. But when you pass that Uuid object into convertToDatabaseValue() for the UuidBinaryOrderedTimeType, then it gets converted into a special type of Uuid, where the bytes are re-arranged for sorting by "ordered time." When you call convertToPHPValue() for the same type, it maintains this special type and returns a Uuid object in which the return value of getBytes() will always return the bytes in the "ordered time" format, even though the hex values a rendered properly, according to the RFC definition.

Does that help clear things up? If not, feel free to ask more questions.

from uuid-doctrine.

Well, you've just reiterated what I already stated in the initial bug report. Rehydrated UUID has a different codec, that affects its behavior (= 'converted into a special type of Uuid, where the bytes are re-arranged for sorting by "ordered time."'). It wasn't there before it hit the db, it doesn't need to be there when it gets back.

from uuid-doctrine.

It wasn't there before it hit the db, it doesn't need to be there when it gets back.

I’m not sure what this means.

When you use the UuidBinaryOrderedTimeType, it converts the UUID into this special type. If you need the bytes to remain the same before and after, use the UuidBinaryType instead to pass the UUID into the database and back.

from uuid-doctrine.

it converts the UUID into this special type.

Right. And it doesn't need to do that, as far as Doctrine type handling is concerned. Type converter gets binary string and returns a UUID. Which has no reason to be any kind of special sub-specie. Could have been ordinary UUID just as well, so it wouldn't be breaking storage transparency.

from uuid-doctrine.

The point of using the OrderedTimeCodec is to rearrange the bytes in just this way.

from uuid-doctrine.