Adds a when() method to the query builder.

[lonnieezell]

Description

This adds a method, when() to the Query Builder that can conditionally modify queries based on the truthiness of a given condition.

Checklist:

• [X] Securely signed commits
• [x] Component(s) with PHPDoc blocks, only if necessary or adds value
• [x] Unit testing, with >80% coverage
• [ ] User guide updated
• [x] Conforms to style guide

[kenjis]

This is an enhancement, so it should go to 4.3 branch, not develop.

[kenjis]

@lonnieezell Only changing the base branch on GitHub will not work. Because you created the PR branch based on develop.

Even if you rebase, if there are commits that have not been merged into 4.3, the PR branch will contain them.

The easy way is to create a new branch from 4.3 and cherry-pick commits that are needed.

[datamweb]

@kenjis , this is a question for me too, if the user has chosen the wrong branch and opens PR. How can he correct it? Please add the necessary explanations to file workflow if possible.

[kenjis]

@datamweb If you have the PR branch feat-abc:

1. Create a new branch feat-abc-new from the correct branch, and cherry-pick the commits you did.
2. Delete the PR branch feat-abc, and rename the new branch feat-abc-new to feat-abc.
3. Force push.
4. On GitHub PR page, change the base branch to the correct branch.

[datamweb]

Great, got it. Thanks.

[kenjis]

@datamweb I sent a PR #6372

[lonnieezell]

@kenjis fixed to point toward 4.3 now

[kenjis]

Please add changelog and link to the details page: https://github.com/codeigniter4/CodeIgniter4/blob/4.3/user_guide_src/source/changelogs/v4.3.0.rst#enhancements

[iRedds]

What if this code is implemented as a trait? It does not depend on the query builder, so it can also be used, for example, on the Response class or model.

[lonnieezell]

Well, looks like pulling in the changes from remote screwed me over here. Will fix that tomorrow.

[iRedds]

I was sure I left a comment on this PR, but for some reason I didn't find it. I must have gotten too old. =)

I would like to suggest reconsidering the idea of this feature.

The when method is not logically related to databases and can be applied to the framework API. It seems to me that it would be more convenient to put this method into a separate trait, which can be added to such classes as Request, Response, Model, and other classes.

In addition to the when method, you can also add the whenNot method.

[lonnieezell]

The when method is not logically related to databases and can be applied to the framework API. It seems to me that it would be more convenient to put this method into a separate trait, which can be added to such classes as Request, Response, Model, and other classes.

In addition to the when method, you can also add the whenNot method.

@iRedds I think that's a great idea. Will do.

[lonnieezell]

Closing this as it's been replaced by #6574