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

Manually merge 2.11.x into 3.0.x #4275

Merged
merged 32 commits into from
Sep 20, 2020
Merged

Manually merge 2.11.x into 3.0.x #4275

merged 32 commits into from
Sep 20, 2020

Conversation

greg0ire
Copy link
Member

Not gonna lie, this was super hard because of:

  • the exception rename
  • the sqlite thingy revert
  • things related to exceptions that happened in the meantime on 3.0.x

Please review super carefully. If it turns out not to be correct and too hard to fix, let's try doing the items above one by one. I used imerge for the merge, which helped a bit I think, but still…

morozov and others added 30 commits August 26, 2020 21:32
Rename
- sp_RENAME to sp_rename;
- SysObjects to sysobjects;
- SysColumns to syscolumns.

Fixes issues with case sensitive collation on mssql database.
Fix errors with case sensitive collation on mssql: not existing procedures and tables (sp_RENAME, SysObjects, SysColumns)
Cleanup Travis scripts and configuration
If there is no constraint name defined the listTableForeignKeys should not invent a new one as a numerical id has no deeper meaning and makes schema changes adding information that was not there before.
Using `null` is an apropriate value as its already in use when handling not existing fk names.
SQLite: Fix wrongly detected reference constraint name on schema change
This is part of an effort to standardize workflows accross repositories.
We do not have a way to do it automatically yet, but it is still nice to
have one reference repository.
Deprecate DBAL\DBALException in favor of DBAL\Exception
Handle both ways of PDO reporting failed connection
Revert full support for foreign key constraints for SQLite
@greg0ire
Copy link
Member Author

greg0ire commented Sep 19, 2020

@morozov as outlined in #4274 (comment), I'm not merging 2.11.x here, but a prior state of it, so I believe the correct diff to compare against would be ce85bd8...cce615a

I could have done all steps in one go, but since step 1 is super complicated already, I figured it would be easier to review like this.

@greg0ire
Copy link
Member Author

Here are the 4 classes that do not appear in the diff of this PR, but do appear in the diff I linked:

  • AbstractSQLAnywhereDriver: does not exist on 3.0.x
  • AbstractSQLServerDriver: does not throw on 3.0.x
  • AbstractSQLiteDriver: already does not have the code that gets removed
  • Mysqli/Driver: no longer throws a DBALException

@morozov
Copy link
Member

morozov commented Sep 19, 2020

OK, so the PR is only expected to not include the changes from #4274 but the second chunk mentioned in the review comment doesn't belong there. Honestly, I don't see much benefit in taking the merge work apart. It adds confusion and complexity and doesn't reduce the amount of work to be done.

Why don't we merge everything at once as we've been doing so far?

@greg0ire
Copy link
Member Author

Why don't we merge everything at once as we've been doing so far?

I thought it would be best to do that because steps 2 and 3 of the plan I described make this non-trivial.

the second chunk mentioned in the review comment doesn't belong there

not sure what you are talking about:

I will try the next steps, hopefully it will make things easier.

@greg0ire greg0ire changed the title Manually merge cce615a9e into 3.0.x Manually merge 2.11.x into 3.0.x Sep 19, 2020
@morozov
Copy link
Member

morozov commented Sep 19, 2020

The chunk missing from the current PR (the changes in AbstractPostgreSQLDriver from #4268) does not belong to #4274, so it should be here but it doesn't seem to.

@greg0ire
Copy link
Member Author

Please compare the diff above and the PR and see if something else is missing.

Ok I think I understood where I messed up. Will tell you when I am done with that.

@greg0ire
Copy link
Member Author

Done, please resume your review.

@morozov
Copy link
Member

morozov commented Sep 20, 2020

Now this PR introduces the getAsciiStringTypeDeclarationSQL() method from #4274 but via the merge commit instead of having 7b58fd2 in the ancestry tree.

@greg0ire
Copy link
Member Author

@morozov fixed, sorry

@morozov
Copy link
Member

morozov commented Sep 20, 2020

This is still not “Merge 2.11.x into 3.0.x”. The 0d9f0ad commit doesn't belong to 2.11.x, and there's 3 merge commits at the end.

Please redo it the normal way. Instead of resolving the conflicts again, you can use the tree in its current state.

@greg0ire
Copy link
Member Author

The 0d9f0ad commit doesn't belong to 2.11.x

This was on purpose. Since gjdanis had already done the work for 3.0.x , I thought it would be simpler to merge this work, which 0d9f0ad represents, and then use the ours strategy to let git know that this is equivalent to merging what gjdanis did on 2.11.x . The 3 merge commits are:

  • merge 2.11.x as it was before gjdanis' contribution
  • merge gjdanis' contribution as it was before you rebased it on 2.11.x
  • merge -s ours 2.11.x current state.

Instead of resolving the conflicts again, you can use the tree in its current state.

Sounds easy enough. Done.

@morozov
Copy link
Member

morozov commented Sep 20, 2020

Since gjdanis had already done the work for 3.0.x , I thought it would be simpler to merge this work, which 0d9f0ad represents, and then use the ours strategy to let git know that this is equivalent to merging what gjdanis did on 2.11.x .

I get the idea but it's not “Merge … into …”, it's something else which we don't normally do. It could be done behind the curtains and documented since it's an implementation detail of the PR, not the intent.

Apart from that, I made a couple of changes during the backport, so if just the original commit was used for merging up, there should have been another one on top (which you had I believe). This whole dance complicates the process hugely and unnecessarily IMO.

@morozov
Copy link
Member

morozov commented Sep 20, 2020

The issue in the SchemaDiffTest must be the last one. The rest looks good.

@morozov morozov merged commit 789d900 into doctrine:3.0.x Sep 20, 2020
@morozov
Copy link
Member

morozov commented Sep 20, 2020

Not gonna lie, this was super hard

Thanks, @greg0ire!

@morozov morozov mentioned this pull request Sep 21, 2020
@github-actions github-actions bot locked as resolved and limited conversation to collaborators Jul 29, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants