New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add Kernel.UUID for eventual UUID primary key in mapper #60

Closed
jc00ke opened this Issue Feb 9, 2015 · 1 comment

Comments

Projects
None yet
2 participants
@jc00ke
Copy link
Contributor

jc00ke commented Feb 9, 2015

Proposing we add UUID so in the mapper we can have

  mapper = Lotus::Model::Mapper.new do
  collection :books do
    entity Book

    attribute :id, UUID   
    attribute :title, String
  end
end

Thoughts?

@jodosha jodosha self-assigned this Feb 10, 2015

@jodosha jodosha added the wontfix label Feb 10, 2015

@jodosha

This comment has been minimized.

Copy link
Member

jodosha commented Feb 10, 2015

@jc00ke Thanks for opening this ticket. We are already discussing about custom coercions in a separated GH issue. hanami/model#36

I recognize that UUID is a "type" as an output of an algorithm. We represent it as a string, but there is difference between "hello" and "20c61826-48c1-4f52-a6fd-f1de26ce0f6a".

However, this can't be implemented as a coercion. The rule of thumb for Utils::Kernel is: try to convert the input into a specific type or raise a TypeError. This guideline works well with "strong types", eg primitives like Integer or Date.

The problem with UUID is to apply this concept. What to do if I get an integer as input? What to do when a non-UUID string is given? Probably we'll raise an error.

In the end, the only input that won't make this function to blow is an object that respond to #to_str or #to_s and returns a valid UUID. But is it worth to have around an algorithm that doesn't complain if the given input is already correct?

Semantically, it looks more like a validation than a coercer. Also, because this would be only introduced because of the mapper, I'm keen to close this ticket and to continue the discussion over there.

@jodosha jodosha closed this Feb 10, 2015

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment