How to validate that value is an Integer with Firebase rules - validation

I'm trying to make sure that some field of an object in firebase is an integer and not decimal. There is a method isNumber() but it returns true wheter value is an integer or a decimal.
I've tried to check a value with regex, but for some reason it works properly only with values within quotation marks ie strings.
This is how my rule looks:
"$item_id":{
"created":{
".validate":"newData.val().matches(/^[0-9]+$/)"
}
}
So when I put an object with string value like this {"created":"123456789"} validation works fine. But when I put an object with number value {"created":123456789} validation fails.
Is there a way to do this?

You cannot use a regular expression to validate a number, since regular expressions match patterns in strings.
You can also not really validate that something is an integer, since JavaScript doesn't have a separate integer vs floating point type. They're all just floating point numbers.
What you can validate is that something is a whole number. The simplest way I could come up with is:
".validate":"newData.isNumber() && newData.val() % 1 === 0.0"
This accepts 1 and 1.0, but will reject 1.1.

Related

Ecto Changeset - How to validate that a field contains only numbers and accepts one decimal point

I'm an Elixir beginner.
I am trying to validate a field for employee working hours. I have an input with an attribute of type="number", however this attribute does not fully work for Internet Explorer 11 so I need back end validation to have browser compatability.
The requirements are:
The field should only ever contain numbers, non-numerical characters should not be valid.
The field is allowed a maximum of one decimal point with a step of 0.5
For example:
"40" should be valid
"37.5" should be valid
"40 Hours" should be invalid
"32.3" should be invalid
"37.55" should be invalid
"37..5" should be invalid
Here's all I got so far:
defp validate_working_hours(changeset) do
changeset
|> Changeset.validate_number(:working_hours, greater_than: 0)
end
How would I go about validating my requirements? I presume validate_format would come in useful here - something along the lines of
|> Changeset.validate_format(:working_hours, <something here>)
But after fiddling around I can't seem to validate these requirements. Any help appreciated, cheers.
You are after Ecto.Changeset.validate_format/4
...
|> validate_format(:working_hours, ~r/^\d+(?:\.[05])?$/)
This regular expression means at least one digit, followed by an optional dot with either zero or five.
Sidenote: please note, that if you ever suppose making this application to be used worldwide, many countries use e. g. the comma (,) for decimal separator and the code must be more cumbersome involving locales.

ruby's Net::HTTPResponse attribute 'code' returns string

Why is the Net::HTTPResponse attribute 'code' returning a string? Coming from other languages this doesn't make sense to me.
The value is not intended to be used for arithmetic or other similar operations. This is similar to why you would choose a character type column over a numeric type column in a database.
This works with the string methods well too. For example, if you want to check that it’s a 3XX error, you can do code.start_with?("3") rather than using < and > operators.

currency validation sholdn't allow zero or a number starts with zero

I have written a regex for currency which shouldn't accept 0 or a number starts with 0
/^\$?(?:\d+|\d{1,3}(?:,\d{3})*)(?:\.\d{1,2}){0,1}$/
But it still accepts 0 and numbers starts with 0.
In general, matching negatives with regular expressions is not the easiest thing to do. One option that would probably make your code more human readable is using multiple regular expressions, e.g., first
if (not /^\$0/)
if (/whatever else you do want it to match/)
// whatever
I think you want /^\$?(?:[1-9][0-9]*|[1-9][0-9]{0,2}(?:,[0-9]{3})*)(?:\.[0-9]{2})?$/. Not sure if that's exactly what you need, but the main point is to match [1-9] for leading digit.
Edit: doesn't allow $.99, but your example doesn't either so not sure if you want that.

Should I just use string as attribute type instead of integer in core-data?

I have a text filed which allows user to input numbers. This is what I did:
[_textfield setText:[NSString stringWithFormat:#"%d", [_textfield.text intValue]]];
Basically, I convert text in text filed to integer, then convert back to string. This will ensure the text is numbers only.
Now I need to store the text in _textfield into core data. I was wondering wether should use string as the attribute type or integer.
I know integer is a more sensible option. But to this case, every time the view is loaded, I need fetch this data and set to the _textfield. If I use integer as the attribute type, I have to convert to string each time. I know what I need to do is simply:
_textfield.text = [numberFromCoreData stringValue];
I don't need to compare, sort or do any arithmetic computation with that number, so should I just use string as the attribute type?
Integer searching is significantly faster than string searching. That is the single most compelling reason to use numbers in your persistence layer. Numbers also can sort differently than strings.
For performance reasons I would never use a string when I know the value is always going to be an integer. Control the input, force it to only accept numbers and keep your data integrity.
It depends how you need to use that field. In almost every case, integer data should be stored as an integer type, but not always. You definitely want an integer type if you'll ever be using that field in a case where its numeric value counts in some way. That includes sorting (because it's a hell of a lot faster with numeric fields), comparing numeric values, or any kind of mathematical operation.
But there's are exceptions. For example, in some cases fields which initially seem to be inherently numeric turn out not to be so. Like a "size" field which is normally an integer. But on closer inspection it turns out that some sizes are specified as "8 - 10", "12 - 14", etc. This happened in one app I worked on a couple of years ago. In that case I ended up using two fields for the data-- a numeric "sortSize" that could be used for sorting, and a string "displaySize" that included the full string.
It's probably not what you want but why don't you use a keyboard type "number Pad" for your textfield?
With that, you would be sure that you have only numbers into your textfield.
Honestly I can't think of a compelling reason. Strings in general take up more storage space than Integers but in the modern world of computing this isn't much of an issue. If you aren't really pushing you processor too hard I'd go with what is convenient.
From the most basic way of thinking about it an integer is a number but for a string the computer needs to know when the string ends, starts, and what is in it so its a little bigger.

NumberFormatException while converting from string to integer in servlet

I know ths is a common question here. I have read the solutions and modified the code then also i am not getting the solution so I have posted my code here.
when I read a value from the text box and parse the value into int from String in servlet, why does it show NumberFormatException?
String ph=request.getParameter("phone");
int phone=Integer.parseInt(ph.trim());// exception is generated here
You can't have any characters or symbols in an int AND the maximum size of an int is 2,147,483,647 which means the phone number 555 555 5555 would be to large to store in an int.
Change the parse to a long and it should fix your problem
A good rule to follow is do not store any number like SSN or Phone numbers's in numerical primitives. You want to leave the numerical primitives for values you plan on doing something math related. Keep them as strings if at all possible.
Because the value you are feeding it is not a valid integer. Make sure it doesn't have strange characters in it.
9835008199 is higher then MAXINT, so that's probaly it.
The docs tell me:
Throws NumberFormatException - if the string does not contain a parsable integer.
On another note: do not store phone numbers as integers. You will get in trouble (you are in fact already). Rule of thumb: if you do not want to do math with a number, it's not an int, but a string.
Use isNumber function to check whether it is a valid number.

Resources