[Pull Request] Support for double data type in schema builder.

[mikeholler]

I've implemented the feature discussed in issue #1955. This patch extends the Schema Builder syntax to include double support for columns. This means the following syntax is possible:

Schema::create('table', function($table) {
    $table->increments('id');
    $table->double('double_col_1');
    $table->double('double_col_2', 15, 8);
});

You'll notice there are two different ways to declare a double, with a specified precision or without. In addition to the simple double syntax, MySQL supports a second, nonstandard syntax.

From MySQL documentation:

MySQL permits a nonstandard syntax: FLOAT(M,D) or REAL(M,D) or DOUBLE PRECISION(M,D). Here, “(M,D)” means than values can be stored with up to M digits in total, of which D digits may be after the decimal point. For example, a column defined as FLOAT(7,4) will look like -999.9999 when displayed. MySQL performs rounding when storing values, so if you insert 999.00009 into a FLOAT(7,4) column, the approximate result is 999.0001.

Both of these syntaxes are supported in this patch, as you'll see in the examples below. It is important to support both syntaxes because documentation for the default M,D in the extended syntax is surprisingly nonspecific, and those of use working on systems that already make use of the standard syntax might lose precision migrating to the extended M,D notation.

Examples

Standard SQL DOUBLE syntax in MySQL is:

$table->double('double_col_1');

Which is translated into:

alter table `table` add `double_col_1` double not null

And the nonstandard MySQL DOUBLE syntax option expressed as:

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

Which is translated into:

alter table `table` add `double_col_2` double(15, 8) not null

[ammont]

+1 for this. thanks.

[carbontwelve]

+1 for this

[mikeholler]

Thanks all! I should add that there is also double support for all four databases laravel supports. MySQL is just the only one of the four that supports the extended syntax. Use the extended syntax using another connector and it will be ignored, just like it does with $table->float('col', 5, 2).

[taylorotwell]

You need a space in between the = signs and the default values. Also why not use the same default values as float?

[mikeholler]

I will add those spaces in. As for the default values, I thought I made my reasoning for the use of null clear in my original post in this pull request, but I'll try to be more explicit here.

The only reason, as far as I can tell, the last two parameters exist in float() is MySQL. The other database grammars ignore the specified $total and $places. If you look at the examples I gave in the first post (reproduced below) you'll see that the SQL generated for MySQL is different based on whether $total and $places are set explicitly or the default values are used. If the defaults were the same as float, you would have to use $table->double('col', null, null) to get the default syntax without the extra parameters, which is a confusing syntax.

With your permission, I'd like to change the default parameters for float in the same way. Also, can you tell me why float()'s default values are 8 and 2? It seems rather arbitrary to me.

Standard SQL DOUBLE syntax in MySQL is:

$table->double('double_col_1');

Which is translated into:

alter table `table` add `double_col_1` double not null

And the nonstandard MySQL DOUBLE syntax option expressed as:

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

Which is translated into:

alter table `table` add `double_col_2` double(15, 8) not null

[mikeholler]

@taylorotwell Spaces have been added. See my comment in response to yours on the outdated diff for my response.

[mikeholler]

Any comments on this? It's been a while...

[carbontwelve]

I'd like to see this included.

[taylorotwell]

Done on 4.0 branch and fixed the various issues.

[taylorotwell]

Just wanted to note I didn't quite feel right with the way I handled this pull request. Since it was to the wrong branch. I just fixed a few things and moved the code to the right branch. Since I work on this project in my spare time and I wanted to just get the issue done I chose to just move the code over. I'm not really comfortable with that decision and wanted to "make it right" so merging this pull request into master now.

Thanks for your contribution!