#860 ✓resolved
eydaimon

there's no way to validate that the original input is an integer

Reported by eydaimon | May 22nd, 2009 @ 11:37 AM | in 0.10.0

class X
  include DataMapper::Resource
  property :my_int Integer
end
f = X.new(:my_int => 33.2)
  1. :format doesn't work, because it only operates on strings.
  2. validate_with_method doesn't work because a typecast to int will have occurred by the time the method is called.

If I do X.new(:my_int => X.new), only then do I get @errors={:my_int=>["My int must be an integer"]}

It seems bad that anything is just silently converted to integer if possible. There should be some kind of strict checking to be passed as an option. (I would strongly argue for that to be default)

Use case: I'm doing a payment system which accepts US currency in cents (active merchant). If a user is entering $100.50 and enters 100.50 instead of 10050, the difference between $1 and $100 is pretty significant.

Comments and changes to this ticket

  • Paul Sadauskas (Rando)

    Paul Sadauskas (Rando) May 23rd, 2009 @ 12:51 AM

    • Assigned user set to “Paul Sadauskas (Rando)”
    • State changed from “unconfirmed” to “not-applicable”

    This is the same problem as #862. As I'm the one that reported it, and there's already a discussion over there, and I'll probably be the one to fix it after 0.10.0 hits, I'm just gonna close this one as a dupe, and link here from the other ticket.

  • eydaimon

    eydaimon May 23rd, 2009 @ 10:35 AM

    Looks like we filed it close to each other. I wonder if you saw the discussion on merb. Either way, I don't care as long as it gets fixed :)

  • Paul Sadauskas (Rando)

    Paul Sadauskas (Rando) May 26th, 2009 @ 01:44 PM

    I have not seen the discussion on merb, would you mind linking it, please?

  • Dan Kubb (dkubb)

    Dan Kubb (dkubb) June 16th, 2009 @ 10:48 PM

    • Assigned user changed from “Paul Sadauskas (Rando)” to “Dan Kubb (dkubb)”
    • State changed from “not-applicable” to “resolved”
    • Milestone set to 0.10.0

    This has been resolved with the following commit:

    http://github.com/datamapper/dm-core/commit/14d107233726f8fb269c2e6...

    I plan to use the same approach to fix #862. Patches are welcome for that to expedite the fix, otherwise it will happen once all known relationship related tickets are resolved and/or if I hit this bug myself -- although since I don't use Float in any apps that isn't likely.

    Also, what do you all think about the support for octal, binary and hex typecasting here? I tried to keep with the Ruby conventions, but now that I've thought about it more, I can't see any valid use cases for passing 0123 and having it treated as octal.. I'd argue that in most cases the intention would be to treat that as the 123 rather than 83.

  • Dan Kubb (dkubb)

    Dan Kubb (dkubb) June 22nd, 2009 @ 10:05 PM

    It looks like the typecasting issues were causing problems with RC1 users, so I pushed a fix for this early. Please try it out with different types of number objects and please let me know if it works for you.

Please Sign in or create a free account to add a new ticket.

With your very own profile, you can contribute to projects, track your activity, watch tickets, receive and update tickets through your email and much more.

New-ticket Create new ticket

Create your profile

Help contribute to this project by taking a few moments to create your personal profile. Create your profile »

Referenced by

Pages