I use the new Parse Server, and in the cloud part which is using Javascript I want to check if an integer is specified by a user, in other words I want to check if the Int is null or not. I can do it for strings, but as I see from comments, an int can not be null. Bu I do not want to change all ints in my code to integers. I try the code below, but it is not working, how can I check if there is a number specified by the user or if it is empty?
if (!req.object.get('number'))
Your code should work as long as number isn't zero. To handle that case as well, simply do a type check like this:
if (typeof req.object.get('number') !== 'number').
It seems like you are confusing java and javascript. Javascript does not have ints or integers, only numbers. Javascript variables do not have types and all variables can be null and undefined.
Related
I am trying to pass a big int to a function from an onclick event in HTML. The ints are always very long, and I cannot seem to pass it to my function without rounding. I have tried some bigInt libraries to the same end, though I would much rather prefer simple string casting.
My js function:
function initBuy(id){
console.log(id.toString());
}
and my HTML event:
<dt></dt><dd><a id="buy" onclick="initBuy(String(' + all_data[index].listing_id + '))" class="btn btn-success">Buy This Item</a></dd>
An example of a passed int:
13934317650292905813
and the result of clicking the button:
"13934317650292906000"
The passed int looks fine when I write it to an elements' text. When I pass it to a function, however, it's rounding it.
From the post here the maximum value an integer in Javascript could take is 9007199254740992
Your number 13934317650292905813 is far bigger than that.
From this post here you can use BigInteger.js to accommodate big integers
You say in your (ambiguous) question:
'The passed int looks fine when I write it to an elements' text. When I pass it to a function, however, it's rounding it.'
and in your comment:
If I set all_data[index].listing_id to an elements text, it works.
That means you are already getting the 'integer' as text-string in JSON.
Nothing in your current question converts the string to a number (I tested it).
As soon as the string would be converted to a number it would overflow IEEE 754's max accuracy of 2^53=9007199254740992.
Note that: initBuy(String(' + all_data[index].listing_id + '))
will return the string + all_data[index].listing_id + (as it should).
Passing the string '13934317650292905813' to your initBuy function also returns string '13934317650292905813' (as it should).
In other words, I can not reproduce your problem using the code you have supplied.
I assume you have simplified your initBuy function for this question (you'd have to post the original one for further examination, preferably together with an excerpt of a relevant part of the raw JSON string).
I assume you might accidentally convert the string to a number (probably using a +) inside that function!
I have an element of type double in my data mapper called capital. the values come from excel spreadsheet. but when there is no capital the values is "N/A" in excel. then i get the following error in the mapper:
Caused by: com.opensys.cloveretl.component.spreadsheet.exception.SpreadsheetException: Cannot get number value from cell of type String in M3 in record 1, field 13 ("Capital"), metadata
How can i script the mapper to return null or 0 whenever a value of type string comes through?
You can use any Java methods available on the data types when you are working with the script. It looks like the problem here is that you don't know if the input value is going to be a String ("N/A") or a decimal value. To solve that, you can take the approach of converting it to a string to test it and then take the appropriate action. I don't have an excel data mapper set up at the moment so I didn't try this out, but I think something like this should work.
output.Captial = ((""+input.Capital).equals("N/A") ? 0 : input.cellValue);
By adding the ("" + input.Capital), you are casting it to a String, just like it would in Java.
I have the following JSON:
[{"hashcode": 4830991188237466859},{...}]
I have the following Angular/JS code:
var res = $resource('<something>');
...
res.query({}, function(json) {hashcode = json[0].hashcode;};
...
Surprisingly (to me, I'm no JS expert), I find that something (?) is rounding the value to the precision of 1000 (rounding the last 3 digits). This is a problem, since this is a hash code of something.
If, on the other hand I write the value as a String to the JSON, e.g -
[{"hashcode": "4830991188237466859"},{...}]
this does not happen. But this causes a different problem for me (with JMeter/JSON Path, which extracts the value ["4830991188237466859"] by running my query $.hashcode - which I can't use as a HTTP request parameter (I need to add ?hashcode=... to the query, but I end up with ?hashcode=["..."]
So I appreciate help with:
Understanding who and why -- is rounding my hash, and how to avoid it
Help with JMeter/JSON Path
Thanks!
Each system architecture has a maximum number it can represent. See Number.MAX_VALUE or paste your number into the console. You'll see it happens at the JavaScript level, nothing to do with angular. Since the hash doesn't represent the amount of something, it's perfectly natural for it to be a string. Which leads me to
Nothing wrong with site.com/page?hashcode=4830991188237466859 - it's treated as a string there and you should keep treating it as such.
The javascript Number type is floating point based, and can only represent all integers in the range between -253 and 253. Some integers outside this range are therefore subject to "rounding" as you experience.
In regards to JMeter JSON Path Extractor plugin, the correct JSON Path query for your hashcode will look like
$..hashcode[0]
See Parsing JSON chapter of the guide for XPath to JSON Path mappings and more details.
I've searched these forums and have found nothing. What I'm trying to find is a function in PHP that will convert a binary representation into a regular integer. parseInt seems to do the trick in JavaScript, but I need a serverside equivalent for the specific program I am creating. Anyone have thoughts?
i.e. parseInt(110100101); in JavaScript returns 421. I need a function that returns the same number with that binary.
bindec will do what you are looking for. You just need to make sure that you are passing it as a string, so if you have as an int, just cast it to a string first
$newInt = bindec( (string) $binaryInt );
Otherwise if its already a string you dont need to cast it to one and can just pass it in:
$newInt = bindec( $binaryString );
I have five digit US zip codes coming out of the database. When JavaScript see them, it treats them as a number and lops off the leading zeros.
How do I get JavaScript to treat the numbers as a string so that they display correctly?
Quote them.
In both JavaScript and JSON 05123 is an octal number equal to 2643 (thanks #Marc B) and "05123" is a string containing only numeric characters.
Don't quote them in your database, of course. You'll want to quote them in the JavaScript or JSON you are generating in the server-side code that's reading the information from the database and passing it to your client-side code. Ordinarily, that's as simple as casting the zip code to a string (or, as is the more likely case, not casting your numeric zips to a number.)
Here's a function which pads a number until it's 5 characters long.
function formatzip(num) {
var s = "00000"+num;
return s.substr(s.length-5);
}
But really the zip code should never have turned into a number in the first place. It should be a string when you set it's value to begin with.
I'm sure that String() would probably work. If by that time, the 0s are already lopped off, you could do something like:
zip = <Source>;
zip = String(zip);
while(zip.length<5){
zip = "0" + zip;
}
Tell me if this isn't what you're looking for.
A guess... Some genius decided to store ZIP codes in a numeric column type inside the database (NUMBER, INT or whatever type your DBMS implements). If that was the case, all ZIP codes that start with zero are already corrupted.
It'd be better to switch the column to VARCHAR before it's too late and fix the corrupted rows manually.