[11.x] Schema Upgrade Guide (#9268)

* wip

* formatting

* formatting

* formatting

---------

Co-authored-by: Taylor Otwell <taylor@laravel.com>

Author: hafezdivandari

upgrade.md

@@ -9,6 +9,17 @@
 
 - [Updating Dependencies](#updating-dependencies)
 - [Updating Minimum Stability](#updating-minimum-stability)
+- [SQLite Minimum Version](#sqlite-minimum-version)
+
+</div>
+
+<a name="medium-impact-changes"></a>
+## Medium Impact Changes
+
+<div class="content-list" markdown="1">
+
+- [Modifying Columns](#modifying-columns)
+- [Floating-Point Types](#floating-point-types)
 
 </div>
 
@@ -19,6 +30,7 @@
 
 - [The `Enumerable` Contract](#the-enumerable-contract)
 - [Spatial Types](#spatial-types)
+- [Doctrine DBAL Removal](#doctrine-dbal-removal)
 
 </div>
 
@@ -50,6 +62,8 @@ You should update the following dependencies in your application's `composer.jso
 
 </div>
 
+In addition, you may remove the `doctrine/dbal` Composer dependency if you have previously added it to your application, as Laravel is no longer dependent on this package.
+
 <a name="collections"></a>
 ### Collections
 
@@ -67,6 +81,53 @@ public function dump(...$args);
 <a name="database"></a>
 ### Database
 
+<a name="sqlite-minimum-version"></a>
+#### SQLite 3.35.0+
+
+**Likelihood Of Impact: High**
+
+If your application is utilizing an SQLite database, SQLite 3.35.0 or greater is required.
+
+<a name="modifying-columns"></a>
+#### Modifying Columns
+
+**Likelihood Of Impact: Medium**
+
+When modifying a column, you must now explicitly include all the modifiers you want to keep on the column definition after it is changed. Any missing attributes will be dropped. For example, to retain the `unsigned`, `default`, and `comment` attributes, you must call each modifier explicitly when changing the column, even if those attributes have been assigned to the column by a previous migration:
+
+```php
+Schema::table('users', function (Blueprint $table) {
+    $table->integer('votes')->unsigned()->default(1)->comment('my comment')->change();
+});
+```
+
+<a name="floating-point-types"></a>
+#### Floating-Point Types
+
+**Likelihood Of Impact: Medium**
+
+The `double` and `float` migration column types have been rewritten to be consistent across all databases.
+
+The `double` column type now creates a `DOUBLE` equivalent column without total digits and places (digits after decimal point), which is the standard SQL syntax. Therefore, you may remove the arguments for `$total` and `$places`:
+
+```php
+$table->double('amount');
+```
+
+The `float` column type now creates a `FLOAT` equivalent column without total digits and places (digits after decimal point), but with an optional `$precision` specification to determine storage size as a 4-byte single-precision column or an 8-byte double-precision column. Therefore, you may remove the arguments for `$total` and `$places` and specify the optional `$precision` to your desired value and according to your database's documentation:
+
+```php
+$table->float('amount', precision: 53);
+```
+
+The `unsignedDecimal`, `unsignedDouble`, and `unsignedFloat` methods have been removed, as the unsigned modifier for these column types has been deprecated by MySQL, and was never standardized on other database systems. However, if you wish to continue using the deprecated unsigned attribute for these column types, you may chain the `unsigned` method onto the column's definition:
+
+```php
+$table->decimal('amount', total: 8, places: 2)->unsigned();
+$table->double('amount')->unsigned();
+$table->float('amount', precision: 53)->unsigned();
+```
+
 <a name="spatial-types"></a>
 #### Spatial Types
 
@@ -87,3 +148,39 @@ $table->geography('latitude', subtype: 'point', srid: 4326);
 ```
 
 The `isGeometry` and `projection` column modifiers of the PostgreSQL grammar have been removed accordingly.
+
+<a name="doctrine-dbal-removal"></a>
+#### Doctrine DBAL Removal
+
+**Likelihood Of Impact: Low**
+
+The following list of Doctrine DBAL related classes and methods have been removed. Laravel is no longer dependent on this package and registering custom Doctrines types is no longer necessary for the proper creation and alteration of various column types that previously required custom types:
+
+<div class="content-list" markdown="1">
+
+- `Illuminate\Database\Schema\Builder::$alwaysUsesNativeSchemaOperationsIfPossible` class property
+- `Illuminate\Database\Schema\Builder::useNativeSchemaOperationsIfPossible()` method
+- `Illuminate\Database\Connection::usingNativeSchemaOperations()` method
+- `Illuminate\Database\Connection::isDoctrineAvailable()` method
+- `Illuminate\Database\Connection::getDoctrineConnection()` method
+- `Illuminate\Database\Connection::getDoctrineSchemaManager()` method
+- `Illuminate\Database\Connection::getDoctrineColumn()` method
+- `Illuminate\Database\Connection::registerDoctrineType()` method
+- `Illuminate\Database\DatabaseManager::registerDoctrineType()` method
+- `Illuminate\Database\PDO` directory
+- `Illuminate\Database\DBAL\TimestampType` class
+- `Illuminate\Database\Schema\Grammars\ChangeColumn` class
+- `Illuminate\Database\Schema\Grammars\RenameColumn` class
+- `Illuminate\Database\Schema\Grammars\Grammar::getDoctrineTableDiff()` method
+
+</div>
+
+In addition, registering custom Doctrine types via `dbal.types` in your application's `database` configuration file is no longer required.
+
+<a name="get-column-types"></a>
+#### Schema Builder `getColumnType()` Method
+
+**Likelihood Of Impact: Very Low**
+
+The `Schema::getColumnType()` method now always returns actual type of the given column, not the Doctrine DBAL equivalent type.
+