Assume the following migration:
Schema::create('tablename', function (Blueprint $table) {
$table->increment('id');
$table->float('some_value');
});
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:
Schema::table('tablename', function (Blueprint $table) {
$table->float('some_value', 8, 6)->change();
});
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:
Schema::table('tablename', function (Blueprint $table) {
$table->double('some_value', 8, 6)->change();
});
This resulted in some doctrine/dbal error stating about an unknown type double
. In the end I had to use the following migration:
Schema::table('tablename', function (Blueprint $table) {
$table->decimal('some_value', 8, 6)->change();
});
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.
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 8, 4
would result in a decimal of the form 0000.0000
.
@ameliaikeda I don't agree that this is a non-issue. Using the current implementation, executing $table->float('some_value');
and $table->float('some_value', 8, 6);
does not produce the same database result (the first creates a DOUBLE(8,2) column and the second a DOUBLE(8,6)). So it stands to reason that executing $table->float('some_value', 8, 6)->change();
should update the column. This is still happening in 5.7.
Agreed with @NoelDeMartin. I'm using ->float()
which creates a 2-precision double which in turn is giving me problems since I'm expecting higher precision. Tried changing it like mentioned above but that doesn't work. So either ->float()
should create some kind of datatype that supports high precision or this function should work as expected. This is all on a MySQL-database by the way
public function up()
{
DB::statement('ALTER TABLE users CHANGE username username VARCHAR(200)');
}
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.
public function up()
{
DB::statement('ALTER TABLE
table_name
CHANGE COLUMN
old_column_namenew_column_name
DOUBLE(8,6) NULL DEFAULT NULL ;');
}
Just did DB::statement('ALTER TABLE table_name MODIFY column_name FLOAT(9,3) NOT NULL;');
after reading this thread and it worked. Thank you, guys 鉂わ笍
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?
Thank you, guys, for your knowledge sharing.
Most helpful comment
@ameliaikeda I don't agree that this is a non-issue. Using the current implementation, executing
$table->float('some_value');
and$table->float('some_value', 8, 6);
does not produce the same database result (the first creates a DOUBLE(8,2) column and the second a DOUBLE(8,6)). So it stands to reason that executing$table->float('some_value', 8, 6)->change();
should update the column. This is still happening in 5.7.