-
Notifications
You must be signed in to change notification settings - Fork 2.5k
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
Add Expr::concat support for multiple arguments #1397
Add Expr::concat support for multiple arguments #1397
Conversation
Hello, thank you for creating this pull request. I have automatically opened an issue http://www.doctrine-project.org/jira/browse/DDC-3717 We use Jira to track the state of pull requests and the versions they got |
07681f4
to
1a0bdae
Compare
1a0bdae
to
61e33e5
Compare
@@ -526,13 +526,13 @@ public function notLike($x, $y) | |||
* Creates a CONCAT() function expression with the given arguments. | |||
* | |||
* @param mixed $x First argument to be used in CONCAT() function. | |||
* @param mixed $y Second argument to be used in CONCAT() function. | |||
* @param mixed $y,... Other arguments to be used in CONCAT() function. | |||
* | |||
* @return Expr\Func | |||
*/ | |||
public function concat($x, $y) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This should have only one argument $x
like the other functions accepting multiple arguments (andX
, orX
and countDistinct
).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sure, I kept the minimum of 2 not to introduce BC. Not supporting 2+ arguments is a bug, since CONCAT DQL expression is now valid syntax, but supporting a single parameters is halfway a bugfix and a feature.
I'll do some test and commit the new change so that the maintainer can review.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@MisatoTremor: @giosh94mhz is correct - removing the param would be a bc break.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@zeroedin-bill well I don't know if this is strictly a BC.
I mean, to stay on the safe side the $y
parameter should be kept, but at runtime is a BC only to add a parameters (w/o defaults), since PHP will ignore extra parameters by default.
You'll have a BC by overriding the method in sub classes, but since this class is part of a Builder pattern is meant to be final anyway.
Am I correct?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@giosh94mhz If the class were actually marked final, it would not matter. Given that it is not actually marked final, someone out there may have extended it. As part of the public API, the intent for this class doesn't really matter. The class is not final, so removing a parameter of this function is indeed a BC break (will raise warnings if it has been extended)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@zeroedin-bill I agree with you. I was just suggesting that the scenario is rare and not recommended due to the Builder pattern, so the maintainer may decide to merge it anyway. Also, this can be merged in master, only partially back-ported to 2.4 and/or 2.5.
61e33e5
to
6a665b8
Compare
I've pushed a new commit which allow Note that since this change the public method |
|
||
$this->secondStringPrimary = $parser->StringPrimary(); | ||
$this->concatExpressions[] = $this->secondStringPrimary; | ||
$this->concatExpressions[] = $parser->StringPrimary(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
All of the changes in this file are unnecessary - DQL CONCAT already supported >2 arguments - The semantics required at least 2 arguments. This change makes it so you can do weird things like CONCAT(field) - That isn't really valid. CONCAT should require a minimum of 2 arguments.
@zeroedin-bill Thanks for the code review, and... well I got the point. I just noted right now that you are tagged as Anyway, I never found a DBMS which yell at me if I do So, if I revert commit |
Sorry for having caused such a fuzz here. |
@giosh94mhz I can guess that @Ocramius will not merge a BC break for this, as this is simply an enhancement, and probably not worth a BC break. Also, I don't know about Oracle, but |
SQL Server always surprise me :) I looked into the Platform and I saw that the actual concat expression is the In the end, the one-parameter scenario is too complicated: BC and Platforms issues are too much for sure. I'll rollback, the last commmit and integrate you suggestion. I'll do my best with whitespaces, but there are some CS issue (carriage-return chars, some tabs, ...). |
6a665b8
to
1617253
Compare
Overall, looks good. @zeroedin-bill: assigning to you for final review/merge (into master - 2.6.0). I think the test needs to be split into a separate method. |
Add Expr::concat support for multiple arguments
Thanks! =) |
DQL CONCAT function support variable number of arguments (2+) since version
2.4.0
.The
Expr
class, on the other hand, is still limited to 2 arguments, and require multiple call to achive a similar result (see this SO question). I've improvedExpr
implementation to support variable number of arguments in a backward compatible way.Please, consider backporting to
2.4
branch if you plan to release other versions, since2.5
introduce many features and may not be possible to easily upgrade. I may be wrong, though.