schema 'float' function generated a 'double' type.

@katarina double is a better float

Please take a closer look at this post

@painis oh, thanks for reply. maybe it's better. but it gonna uses 8 bytes not like float, just 4 bytes. is there a way to generate a 'float' field using Laravel Schema?

You can also do something like this:

public function up()
{
    DB::statement('ALTER TABLE `insert_your_table_name` ADD `field_name` FLOAT NOT NULL');
}

@katarina a double is a float when you tell it how many bytes you want it to take up.

DOUBLE equivalent with precision, 15 digits in total and 8 after the decimal point.

$table->double('column', 15, 8);

You can check the Database Migrations docs for Laravel 5.1 (it has been moved from the Schema Builder from version 5 if that's what you're using.)

@painis @mstnorris i've already known all these stuff. but the problem is how could they let 'double'-function do 'float'-function's job in the Schema. if i need a double type, absolutely will use the 'double'-function. eh,,, so annoying. anyway, many thanks for ur reply, guys. :)

This is stupid. If I want a double, I would have asked for one. Why is laravel forcing me to use a double? It's like going into McDonalds and asking for a hamburger but give you a salad because its better for you.

It's pretty stupid that this is even an issue.

I am in a situation where my company is needing to recreate an existing database structure using Laravel migrations for an existing enterprise-grade application for a big client. This existing database uses a column on a table like this:

`foobar` float unsigned NOT NULL DEFAULT 0,

The tables created through migrations have to match EXACTLY because there are various database description checks that the system does on the tables in order to verify integrity, etc.

Because Laravel's migration thinks it's going to be Mr. Smarty Pants and give me a Double instead of a Float when I specifically ask for Float, the application fails. Now I have to write a RAW SQL command as answered in this question in order for this to work properly, which completely defeats the purpose of using the ORM to begin with.

You can explain to me all you want how DOUBLE is the same thing as FLOAT, but MySQL/Maria has the FLOAT type there for a reason and restricting people from being able to specify that (and in fact misleading them by calling the method ->float()) is not a good way to development something.

You know how everyone absolutely hates and makes fun of Microsoft Word because it tries to "auto format" your document for you because it thinks it knows better than you, but in fact it does a terrible job at it? Yeah. This is the same thing as that.

I know this is old and I know that there are other examples of things like this, but this is super annoying to finally end up here after going through all the GitHub comments, being sent to Stack Overflow, and finally here to see how to actually solve this. If you have a method called float and it's nothing but an alias for double with 8, 2 precision, then don't call it a float.

It's the same thing for binary, it doesn't create a binary column, it creates a blob. If you want to actually create a binary you have to do:

$table->char('some_column', $length = 16)->charset('binary');

Applies as well to uuid, which is also another alias that doesn't actually create a uuid column. And I'm sure there are more.

They either need to set these methods to return what you're actually looking for, add methods like realFloat and realBinary and realUuid, or update the documentation to let users know that hey, this won't actually make what it says it will.

Any of those options would be way better than terse comments dripping with attitude...