Mapper relations fail when primary keys are binary

[Peace-N]

We are currently facing a challenge here, we are using custom types that we have registered with Dbal and the types are uuid_binary_ordered_time, the Mapper relations fail when primary keys are binary and stored in this type, infact it actually ignores.

We have tested with primary keys as strings and integeres and relations work fine. Has anyone of you ever tried this ?

[FlipEverything]

As said before (#197), you should use a numeric primary key with Spot.... It doesn't hurt....

Personally I think that would be opening a can of worms. Easy and working solution is just to use add numeric primary key as Spot requires. Primary keys are not supposed to contain any business logic anyway. You cannot cater to everyone.

Also Spot requires a primary key that is numeric because there are some "is_numeric()" checks for Mapper::get(), Mapper::delete() and so on.

[Peace-N]

Thank you for your Feedback, can this be a feature request ?

[FlipEverything]

It sure can be, but I don't think that's a priority for us right now.

[Peace-N]

I will have to add this on to the ORM and create a pull request . Have made it work out of its box .

[vlucas]

I have not tried this, but it seems like it should be possible and a supported use case for Spot. UUIDs are valid identifiers, and are commonly used in distributed systems instead of auto-incremented ids. Can you do some digging on this @Peace-N and maybe submit a PR with the code required to support it? I don't have any system configured like this to test with.