Closed gremo closed 4 years ago
Just to be clear: @wbloszyk you committed this with @OskarStark . @greg0ire you released this in 3.17.1.
Commit 331446b was included in release 3.17.1 changing the foreign keys behavior.
Is a patch version (from 3.17.0 to 3.17.1) supposed to do such a breaking change? Does commits gets reviewed, in terms of semantic version and impact on other people applications/sites? Why when something is updated in the Sonata ecosystem... is guaranteed that something will break? Why Sonata seems to be the least stable software in the PHP world?
Is a patch version (from 3.17.0 to 3.17.1) supposed to do such a breaking change?
No
Does commits gets reviewed, in terms of semantic version and impact on other people applications/sites?
We try to.
Why when something is updated in the Sonata ecosystem... is guaranteed that something will break? Why Sonata seems to be the least stable software in the PHP world?
This can happen with open source. There is a lot of work to do and only a few contributors, working on they spare time for Sonata with no sponsor. I you're no happy with it and think you can do better, build your own software ; nobody force you to use it ;)
Why Sonata seems to be the least stable software in the PHP world?
Because you @gremo do not review the PRs. Please watch the repositories and start doing so. If that does not work out, at least you will have gained a deep understanding of why such failures can happen.
@gremo
Just to be clear: @wbloszyk you committed this with @OskarStark . @greg0ire you released this in 3.17.1.
Agree
Commit 331446b was included in release 3.17.1 changing the foreign keys behavior.
Agree
Is a patch version (from 3.17.0 to 3.17.1) supposed to do such a breaking change? Does commits gets reviewed, in terms of semantic version and impact on other people applications/sites? Why when something is updated in the Sonata ecosystem... is guaranteed that something will break? Why Sonata seems to be the least stable software in the PHP world?
Are you read LICENSE? Are you read PR descriptions? Are you revert this PR and check is it working?
Is a patch version (from 3.17.0 to 3.17.1) supposed to do such a breaking change?
No
Does commits gets reviewed, in terms of semantic version and impact on other people applications/sites?
We try to.
Why when something is updated in the Sonata ecosystem... is guaranteed that something will break? Why Sonata seems to be the least stable software in the PHP world?
This can happen with open source. There is a lot of work to do and only a few contributors, working on they spare time for Sonata with no sponsor. I you're no happy with it and think you can do better, build your own software ; nobody force you to use it ;)
Just because it's open source it has not to be bad, full of bugs or not following semver, at least. And for sure, can't put that commit in a patch version.
@gremo
Just to be clear: @wbloszyk you committed this with @OskarStark . @greg0ire you released this in 3.17.1.
Agree
Commit 331446b was included in release 3.17.1 changing the foreign keys behavior.
Agree
Is a patch version (from 3.17.0 to 3.17.1) supposed to do such a breaking change? Does commits gets reviewed, in terms of semantic version and impact on other people applications/sites? Why when something is updated in the Sonata ecosystem... is guaranteed that something will break? Why Sonata seems to be the least stable software in the PHP world?
Are you read LICENSE? Are you read PR descriptions? Are you revert this PR and check is it working?
Honestly, can't understand what you are saying. It's your PR, you fixed some related to MSSQL, good to know.
Your PR says a generic sentence: change some database cascade delete. So, how can people migrate to a new settings? Where is documented?
Why Sonata seems to be the least stable software in the PHP world?
Because you @gremo do not review the PRs. Please watch the repositories and start doing so. If that does not work out, at least you will have gained a deep understanding of why such failures can happen.
This can't be a serious answer. Instead of explaining why you actually published 3.17.1 with a big BC, you prefer to make some irony and get some thumbs up.
You know (or can't you remember?) that I contribute to Sonata project with some, probably minor, fixes and patches. You can always ping if you like to review some PR, if you are too busy with your work.
This can't be a serious answer
It is not completely serious as you guessed. If you want an explanation, I just didn't spot the BC break. Are you sure you would have spotted it if you were in my shoes?
You know (or can't you remember?) that I contribute to Sonata project with some, probably minor, fixes and patches.
I know full well and sorry, but it doesn't warrant such a behavior. As thankful as we are for your contributions, it doesn't mean we can accept your bullying.
You can always ping if you like to review some PR, if you are too busy with your work.
The influx of PRs is constant, if I start pinging you on PRs I don't have time to review, you are going to go literally crazy. That's where my answer is not completely joking. If you really want to know why there can be this kind of mistakes, just try keeping up with the PRs on Sonata for a while, you will inevitably end up missing something because it's just too much. Maybe after that you will be more compassionate to people that literally do free work for you.
@greg0ire don't get me wrong. I'm to trying to make you feel "guilty" or blame @wbloszyk for a totally unintelligible PR. I also love open source, made a few projects, trying to help people and trying to not break other people work. Open source doesn't mean "I don't give a f*** if something breaks, we do what we want, read the LICENSE". There should be a minimum of responsibility.
I'm not bullying just because I've submitted a few PR. I'm just saying that Sonata could be a good piece of software, but we/you MUST pay attention when people submit such a "delicate" PR and not blindly accept, merge and release such undocumented change.
Anyways, back to the topic, I think that:
Let's leave this discussion. We have issue to resolve.
For now sonata-project don't support all sql platform (mssql, probably some other too). https://github.com/sonata-project/dev-kit/issues/689
I think all sonata-project working on doctrine, so we can extends bundles configuration by new option entity_manager
: '@doctrine.entity_manager'. From this manager we can get platform. Then we can load cascade behaviors for mysql, triggers for mssql ...
@wbloszyk can you explain what exactly doesn't work with MSSQL? If I understand right, Doctrine can't support MSSQL?
'onDelete' => 'CASCADE'
)remove
)such undocumented change
It's documented at length here: https://github.com/sonata-project/dev-kit/issues/689 (which is linked in the PR, BTW)
@greg0ire don't get me wrong. I'm to trying to make you feel "guilty" or blame @wbloszyk for a totally unintelligible PR.
Your should proofread your sentence, one could argue this one is unintelligible if they wanted to be sarcastic. And with your tone, I can tell that this feel a bit judgmental, coming from someone who maintains OSS projects that are nowhere near the size of Sonata. What you achieved looks great, but sorry, it's just not the same thing. You don't get several pages of Github notifications per day, do you?
That said, I agree with you that this should be reverted, you (or anybody really, but certainly not me) can make a revert PR, and I will merge and release it, then we can make another attempt to get actual compatibility with all DBs, and give the foreign key issue a closer look.
@greg0ire ok let' stop. I agree with you that the number of Sonata issues is really high in respect of a few project I maintain. But there is a community, just ask if you need some help. Sorry for being too much aggressive.
Anyways, I recently made a project using (as second doctrine connection) a MSSQL database. I never had issues at least with onDelete="CASCADE"
issue. Didn't tested any cascade Doctrine behavior yet.
I can post some dumps if you ask or any other information.
Example property:
/**
* @ORM\ManyToOne(targetEntity="RmaRequest", inversedBy="lines")
* @ORM\JoinColumn(nullable=false, onDelete="CASCADE")
*
* @var null|RmaRequest
*/
private $rmaRequest;
I was using ODBC driver for Linux, version 13. No warnings or errors, it just work as expected.
EDIT: now I see that this is related to cycles (that i don't have).
Sorry for being too much aggressive.
Apology accepted. I understand how frustrated you are. To answer your questions more fully, I don't use Sonata, which means I don't even have a project on which to test things. Besides, I wouldn't know where to start when it comes to installing mssql. And last but not least, it would just take too much time, which means we rely solely on unit tests and static analysis for catching bugs. IIRC there have been attemps to add functional tests, but I don't think they ended up being merged. I will let you sort this out with @wbloszyk, you're in a much better position than me to fix this.
@gremo @greg0ire
All (expect 1) my contributions are for sonata-project. As you wrote sonata-project is huge OSS project. I using it in almost all my projects. This mean it is very important for me to keep it bug free. That why i working on sandbox 3.0 where we can run functional test based on behat.
My commits make this bug. I made it base on: https://stackoverflow.com/questions/27472538/cascade-remove-vs-orphanremoval-true-vs-ondelete-cascade
I will check it again and try release fix today.
Environment
Sonata packages
Symfony packages
PHP version
Subject
The
CASCADE
option for the foreign keyparent_id
has been removed from the . Defaults toRESTRICT
. This is the offending commit.Steps to reproduce
Create a block using the page composer. Assign it to a "zone" defined using the configuration. Then remove it.
Expected results
The block is removed.
Actual results
Throws, because the database fails to remove the row.