Skip to content
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

[9.x] Add support for native column modifying #45281

Closed
wants to merge 19 commits into from
Closed

[9.x] Add support for native column modifying #45281

wants to merge 19 commits into from

Conversation

hafezdivandari
Copy link
Contributor

@hafezdivandari hafezdivandari commented Dec 12, 2022

@morloderex
Copy link
Contributor

morloderex commented Dec 15, 2022

@hafezdivandari

That statement changes the data type from INT to BIGINT, but it also drops the UNSIGNED, DEFAULT, and COMMENT attributes. To retain them, the statement must include them explicitly:

It's it a pretty big breaking change sense i would assume that just changing the coumn type would keep any other attributes as it currently does when using doctrine?

@hafezdivandari
Copy link
Contributor Author

@morloderex It won't be a breaking change because it only applies to those who doesn't use DBAL currently or has called Schema::useNativeSchemaOperationsIfPossible config method explicitly.

@morloderex
Copy link
Contributor

@morloderex It won't be a breaking change because it only applies to those who doesn't use DBAL currently or has called Schema::useNativeSchemaOperationsIfPossible config method explicitly.

@hafezdivandari okay, but what would happen if I already have doctrine installed and then I decide to drop it from my project.

Isn't it a breaking change in that regard or would that be considered unexpected behavior?

@hafezdivandari
Copy link
Contributor Author

@morloderex it's not a breaking change nor an unexpected behavior in my opinion, you would expect a change when you add/drop a package. if you want to see an exception when DBAL is not available, like before this PR, you may call Schema::useNativeSchemaOperationsIfPossible(false) .

@hafezdivandari hafezdivandari marked this pull request as ready for review December 19, 2022 23:29
}

$value = $column->{$attributeName};
$value = $column->{lcfirst($commandName)};
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please explain the reason for this change. Seems breaking.

Copy link
Contributor Author

@hafezdivandari hafezdivandari Dec 20, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's not breaking, many tests would fail if it was. I removed this if condition from here and added to L132-L140 of this file. Because unfortunately this method doesn't have $connection argument. I didn't want to change the signature of this method (I'm not quit sure if passing the $connection to this method and changing it's signature is a breaking change so I didn't do that). Please let me know if the comment on L135-L137 that explains why this change is needed is clear.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

TLDR; it's removed from here and added (with more conditions) to its parent method.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's for handling comment on PostgreSQL and default on SQL Server`.

if ($this->hasAutoIncrementColumn() && ! $this->creating()) {
array_unshift($this->commands, $this->createCommand('autoIncrementStartingValues'));
}

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please explain this change.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's to handle auto-increment starting value using from modifier, before this PR from was only supported when adding a column and creating a table. I removed this from compileAdd and add it here to handle both add and change. now it is supported to use from modifier with change.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actually it's much cleaner to handle auto-increment starting value as a fluent command for MySQL and PostgreSQL. but I didn't want to change a lot of code at once and make it hard to review.

@@ -1794,7 +1801,7 @@ public function getChangedColumns()
*/
public function hasAutoIncrementColumn()
{
return ! is_null(collect($this->getAddedColumns())->first(function ($column) {
return ! is_null(collect($this->columns)->first(function ($column) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why no longer using getAddedColumns?

Copy link
Contributor Author

@hafezdivandari hafezdivandari Dec 20, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It now supports both added and modified columns (looking for from modifier on all columns). $this->columns = $this->getAddedColumns() + $this->getChangedColumns()

$column->default(new Expression('CURRENT_TIMESTAMP'));
}

return 'datetime';
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please explain need for this change.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

to be consistent with other Grammars, I changed SQLite too to use the same syntax for handling useCurrent.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

there are 2 different statements to change column type and default value on PostgreSQL and SQL server.

@hafezdivandari
Copy link
Contributor Author

hafezdivandari commented Dec 28, 2022

@taylorotwell I think it is much cleaner to send this PR to master instead, the Blueprint and Grammar classes need some cleanup after years, before supporting native column modifying, do you agree? if yes, please let me know if you prefer series of little PRs or all changes at one PR?

@taylorotwell
Copy link
Member

Sure, you can send a single PR to master.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants