I have had to work in a project where we have an identifier in HEX.
Example, B900001752F10001, is received in a parser developed in JAVA in a SIGNED LONG variable. We store that variable in a SIGNED BIGINT variable in MySQL DB.
Every time we need the HEX Chain we use HEX(code) function and we get what is expected.
But when we have to provision the master table, we need to input valid codes, to achieve that we used something like:
Update employee set code=0xB900001752F10001 where main_employee_id=1002;
it worked in the past producing code to be stored in DB as
13330654997192441857
but now we are using the same exact instruction and we are getting code stored in DB as
-5116089076517109759
So Comparing those two numbers by using HEX function, those provide the same HEX NUMBER.
select HEX(-5116089076517109759), HEX(13330654997192441857)
0xB900001752F10001, 0xB900001752F10001
Could someone please provide ideas why this is happening? How we should handle this from the provisioning perspective we need to assure storing as 13330654997192441857 so when an authentication event happen codes match.
I have run without any other idea, I appreciate any help.
I think you have overflowed the datatype.
According to MySQL manual, signed bigint is in the range of
-9,223,372,036,854,775,808
to
9,223,372,036,854,775,807
Your number
18,446,744,073,709,551,615
has exceeded the above positive bound so it overflows and is
interpreted as a negative number.
Having that said, I think you may still be okay with your command -- it is only when you try to interpret the hex pattern as a number the result looks confusing.
Update employee set code=0xB900001752F10001 where main_employee_id=1002;
64bite machineļ¼top digit is sign bit,so the biggest num is 9,223,372,036,854,775,807,but if ur num more than it,the top digit will transform to be 1,so the num will be negative and its overflowed.
so ur 13330654997192441857 will become to 5116089076517109759.
Related
I was wondering how to construct a Turing Machine for
A<B<C<D...<N
with all numbers (A,B,C,D,...,N) being positive binary numbers.
These are a couple examples of how the machine should work:
1001 - Accepts because there is only one number
0<1 - Accepts
0010<1000<0001 - Doesn't accept because 1000!<0001
0100<1010<1010<1000 - Doesn't accept because 1010!<1010
I've tried methods that work to compare only two numbers but I can't seem to find a way to compare multiple (should work for infinite number of inputs) numbers.
Here is a high-level block diagram for solving this problem. You can implement these blocks by using block feature of JFLAP.
Blocks Description
Done? : This block decides whether all comparisons are done, if yes, it accepts, otherwise, it goes to compare the very next two numbers.
A<B : This block is responsible to compare two binary numbers, the one that cursor is pointing at the first digit and the next one. You can use '<' as the separator between A and B and the next number.
cleanup: during the comparison, you might marked 0's and 1's to something else. This block clean up everything and prepare everything for the next comparison.
Hopefully, this gives you an idea to solve the problem.
I want to know if BigInt is enough in size.
I have created a registration.php where the user gets emailed an account activation link to click to verify his email so his account gets activated.
Account Activation Link is in this format:
[php]
$account_activation_link =
"http://www.".$site_domain."/".$social_network_name."/activate_account.php?primary_website_email=".$primary_website_email."&account_activation_code=".$account_activation_code."";
[/php]
Account Activation Code is in this format:
$account_activation_code = sha1( (string) mt_rand(5, 30)); //Type Casted the INT to STRING on the 1st parameter of sha1 as it needs to be a STRING.
Now, the following link got emailed:
http://www.myssite.com/folder/activate_account.php?primary_website_email=my.email#gmail.com&account_activation_code=22d200f8670dbdb3e253a90eee5098477c95c23d
Note the account activation code that got generated by sha1:
22d200f8670dbdb3e253a90eee5098477c95c23d
But in my mysql db, in the "account_activation_code" column, I only see:
"22". The rest of the activation code is missing. Why is that ?
The column is set to BigInt. Is not that enough to house the Sha1 generated code ?
What is your suggestion ?
Thank You
Hashing methods like SHA-1 produce binary values that are on the order of 160+ bits long depending on the variant used. The common SHA256 one is 256 bits long. No cryptographic hash will fit in a 64-bit BIGINT field because 64-bit hashes are uselessly small, you'll have nothing but collisions.
Normally people store hashes as their hex-encoded equivalents in a VARCHAR(255) column. These can be indexed and perform well enough in most situations, especially one where you do periodic lookups based on clicks. From a performance and storage perspective there's no problems here.
Short answer: BIGINT is way too small.
A hash is basically a stream of bits (160 bits in the case of SHA-1). While it's certainly possible to render those bits as a base 2 number and convert it to base 10, you need a really big storage to do so (as far as I know it's not common to see integer variables larger then 64 bits) and there aren't obvious advantages. BIGINT is a 64-bit type, thus cannot do the job.
Unless you have a good reason to store it as number, I'd simply go for either a binary column type or its plain-text hexadecimal representation in a good old VARCHAR (the latter tends to be more practical to handle).
You are trying to store a string in a BigInt. That is your issue. SHA hashes are a mix of alphanumeric characters not just numbers. Change the field to a VARCHAR and you'll be fine
I need a column to store credit card numbers and the int size isn't sufficient. However, I keep getting the following message, when trying to set the data type to a bigInt. Any suggestions?
If you remove the brackets, it will work.
Use BIGINT
instead of BIGINT()
Don't use integers for credit cards. It's not meant to be treated as a numerical data.
Technical reason is that the card number can have a leading zero, which would get truncated.
Use strings.
In general, I have double values that I work with. I use them as double values and also as strings (in application code). I store them as Double in my MySQL database.
The problem I have is with trailing 0's. For example, the value I get is 10.60. This value gets truncated down to 10.6 which is not ok for me. I need that trailing 0.
I also need it to not add 0's. For example, if I got 10.60, it should not add 0's to be 10.600. I am not sure which data type fits my needs. It needs to be stored as the double value, but keep its trailing 0's, and not add any additional 0's.
Can anyone assist me in which data type to use?
I would store the double values in a double/real field only and not varchar so as to not lose any precision during conversion. Since the issue is only in application code, I would round them to the appropriate decimal places (using the ROUND() function) while retrieving from the database.
I've got a MySQL database with a large amount of 2048-bit binary strings (e.g '0111001...0101'). One calculation I'll need is the Hamming Distance (the total count of 1's in the XOR'd result) of these strings compared to some externally generated bitstring. In order to get an idea of how to write this query, I tried writing it for smaller bitstrings. Here's an example:
select BIT_COUNT(bin((b'0011100000') ^ (b'1111111111')))
The inner portion that computes the XOR works correctly, but BIT_COUNT returns strange results. This example returns 14, which is longer than the string itself.
So I have a few questions:
First, why is BIT_COUNT returning such strange results. Is it operating on a string rather than the binary string I'd like it to operate on? If so, how do I deal with this?
Second, notice that I'm casting (is that the right word here?) the strings as binary by prepending with a b. How would I do this with column names and variables? Clearly I can't simply prepend a b to a variable name, and I can't insert a space between. Any ideas?
Thanks,
EDIT:
So here's a solution to the first problem:
select BIT_COUNT(b'0011100000' ^ b'1111111111')
There seems to be a problem when using this for larger strings (2048 bits). I tried:
select BIT_COUNT(b'001110...00011')
and it gives me results like 28, when the actual bitcount should be around 1024. If I remove the b, then it appears to max-out at 64. Any ideas on how to resolve this problem?
Just remove bin function. With it BIN_COUNT treats its argument as a chars string, not as a set of bits. So
select BIT_COUNT(b'0011100000' ^ b'1111111111')
will do the work