-
-
Notifications
You must be signed in to change notification settings - Fork 1.3k
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
Conversation
Update PHPStan to 0.12.40
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.
Reuse global coding standard workflow
Deprecate DBAL\DBALException in favor of DBAL\Exception
Handle both ways of PDO reporting failed connection
This reverts commit f0c1af4.
This reverts commit 85a983c.
…ema change" This reverts commit 7570aeb.
Revert full support for foreign key constraints for SQLite
Setup automatic release workflow
@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. |
Here are the 4 classes that do not appear in the diff of this PR, but do appear in the diff I linked:
|
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? |
I thought it would be best to do that because steps 2 and 3 of the plan I described make this non-trivial.
not sure what you are talking about:
I will try the next steps, hopefully it will make things easier. |
Ok I think I understood where I messed up. Will tell you when I am done with that. |
Done, please resume your review. |
@morozov fixed, sorry |
This is still not “Merge 2.11.x into 3.0.x”. The 0d9f0ad commit doesn't belong to Please redo it the normal way. Instead of resolving the conflicts again, you can use the tree in its current state. |
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
Sounds easy enough. Done. |
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. |
The issue in the |
Thanks, @greg0ire! |
Not gonna lie, this was super hard because of:
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…