Replace usages of db_or() and db_and().

In concept I'm fine with this. I'd prefer something a bit less verbose than andConditionGroup(), but removing the wrapper functions is fine by me.

Could just as easily be marked @deprecated. As long as we replace the usages in core, doesn't matter much to me.

+1 for the change.

Could just as easily be marked @deprecated.

I see no purpose of this issue then :).

Updated issue summary.

first go at this.

undoing one views file that just doesn't have a query object accessible to the methods creating the conditions. It's probably going to need a refactor of some sort.

got a fix for views. The issue with search is the object returned by db_query does not have the method orConditionGroup on it. That hasn't been addressed yet.

+++ w/core/includes/database.inc
@@ -534,6 +534,8 @@ function db_next_id($existing_id = 0) {
+ * @deprecated use $query->orConditionGroup()

@@ -544,6 +546,8 @@ function db_or() {
+ * @deprecated use $query->andConditionGroup()

Should be marked when to remove, suppose 9.0

Functions were already marked deprecated in #1894396: Mark db_*() wrappers in database.inc as @deprecated for 9.x.

If they're marked deprecated that means working to remove their usage is entirely OK and encouraged for Drupal 8.

Setting to 8.1.x because I think that's where code cleanup type stuff is supposed to happen. Happy to be mistaken.

Setting parent issue to #2319859: [META] Deprecate contents of database.inc

Note that db_or() and db_and() have simple replacements spelled out in their @deprecation docs, so I'm adding the 'needs issue summary update' tag.

 * @deprecated as of Drupal 8.0.x, will be removed in Drupal 9.0.0. Create
 *   a \Drupal\Core\Database\Query\Condition object, specifying an AND
 *   conjunction: new Condition('AND');
[..]
 * @deprecated as of Drupal 8.0.x, will be removed in Drupal 9.0.0. Create
 *   a \Drupal\Core\Database\Query\Condition object, specifying an XOR
 *   conjunction: new Condition('XOR');

Hi,
I'm uploading a new patch based on the comment on #17: replacing db_and and db_or with Drupal\Core\Database\Query\Condition objects.

I have cleaned up the tags for the issue and tried to rewrite the summary in order to reflect the problem and solution.

I am reparenting this to a new meta.

Re-roll.

All code changes are good.
All instances of the usage of db_and() and db_or() are replaced.
The patch looks good to me.
Two minor documentation nitpicks can be fixed on commit.

1. +++ b/core/modules/search/src/ViewsSearchQuery.php
   @@ -74,8 +74,9 @@ function conditionReplaceString($search, $replace, &$condition) {
   +          // As conditions can have subconditions,
   +          // for example new Condition('OR'),
   +          // the function has to be called recursively.
   

   Documentation should be filled out to the 80 character line.

2. +++ b/core/modules/views/src/ManyToOneHelper.php
   @@ -269,7 +270,7 @@ public function addFilter() {
        // add_condition determines whether a single expression is enough(FALSE) or the
   -    // conditions should be added via an db_or()/db_and() (TRUE).
   +    // conditions should be added via an new Condition('OR')/new Condition('AND') (TRUE).
   

   The no documentation beyond the 80 character line rule is broken.

Let's fix those docs errors in the patch. :) Thanks!

Applying the patch as suggested in the comment #26 , please review .

Only documentation changes so setting back to RTBC.

Committed 23d140f and pushed to 8.4.x. Thanks!

diff --git a/core/modules/search/src/ViewsSearchQuery.php b/core/modules/search/src/ViewsSearchQuery.php
index 95aaab8..e61a7e0 100644
--- a/core/modules/search/src/ViewsSearchQuery.php
+++ b/core/modules/search/src/ViewsSearchQuery.php
@@ -74,8 +74,8 @@ function conditionReplaceString($search, $replace, &$condition) {
       $conditions =& $condition['field']->conditions();
       foreach ($conditions as $key => &$subcondition) {
         if (is_numeric($key)) {
-          // As conditions can have subconditions,for example
-          // new Condition('OR'),the function has to be called recursively.
+          // As conditions can be nested, the function has to be called
+          // recursively.
           $this->conditionReplaceString($search, $replace, $subcondition);
         }
       }
diff --git a/core/modules/views/src/ManyToOneHelper.php b/core/modules/views/src/ManyToOneHelper.php
index 3afc196..d9ed2ca 100644
--- a/core/modules/views/src/ManyToOneHelper.php
+++ b/core/modules/views/src/ManyToOneHelper.php
@@ -269,9 +269,8 @@ public function addFilter() {
       $options['group'] = 0;
     }
 
-    // add_condition determines whether a single expression is enough(FALSE)
-    // or the conditions should be added via an new Condition('OR')/
-    // new Condition('AND') (TRUE).
+    // If $add_condition is set to FALSE, a single expression is enough. If it
+    // is set to TRUE, conditions will be added.
     $add_condition = TRUE;
     if ($operator == 'not') {
       $value = NULL;

These original comments are a bit odd I've tried to make them a bit simpler and less about the code and more about what is actually relevant.