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
[5.2+] Cannot alter float precision in migration using ->change()
#13773
Comments
This is a non-issue and a misunderstanding of how the float and decimal types work in databases. A float(ing point) doesn't have exact precision, but allows (many) more than two decimal places. A decimal is exact precision, and |
@ameliaikeda I don't agree that this is a non-issue. Using the current implementation, executing |
Agreed with @NoelDeMartin. I'm using |
The above should work for few of the situations. |
Yes, it is an issue and "change()" should work. But until it does, you can solve the problem with a SQL statement. |
Just did P.S: In 5.8 the issue still exists. However, it seems to be doctrine/dbal, not Laravel. |
This is an awful issue, why is it closed? |
->change()
?->change()
Thank you, guys, for your knowledge sharing. |
The better option is:
|
Assume the following migration:
This generates a float column with precision of 2. I needed to alter this to have more decimal places. I created this migration to change it:
This migration runs fine, but the float is still using only 2 decimal places. This lead me to try and change it to a double:
This resulted in some doctrine/dbal error stating about an unknown type
double
. In the end I had to use the following migration:This ran through fine and now I had a table column which allows more than 2 decimal places.
Is this how the float is supposed work:
Please let me know if you cannot replicate this issue and I'll try to run through it again to see whether I messed up somewhere. I'm running Laravel 5.2.* and the database is a MariaDB 10.1 on Ubuntu 14.04 with PHP7.
EDIT: right now I noticed values 3 and 6 for
decimal('col', 3, 6)
did not work as 3 stands for the full amount of digits, not just the ones on the left side of the decimal. So the confusion there has been cleared.float('col', 8, 6)
does not work anyway, and results in a 2 decimal place precision.The text was updated successfully, but these errors were encountered: