Changed the filter functionality to a condition object
3 unresolved threads
3 unresolved threads
Closes #3476175
Merge request reports
Activity
added 1 commit
- be577166 - 3476175:Change the filter in the overview page of the dblog module to a condition object
added 23 commits
-
be577166...cec21638 - 21 commits from branch
project:11.x
- caa2205a - Merge branch '11.x' into 3476175-change-the-filter
- 7159ca1b - Added return type hint to DbLogController::addFilterToQuery()
-
be577166...cec21638 - 21 commits from branch
304 303 /** 305 304 * Builds a query for database log administration filters based on session. 306 305 * 306 * This method retrieves the session-based filters from the request and applies 307 * them to the provided query object. If no filters are present, the query is 308 * left unchanged. 309 * 307 310 * @param \Symfony\Component\HttpFoundation\Request $request 308 311 * The request. 312 * @param \Drupal\Core\Database\Query\SelectInterface $query 313 * The database query. 309 314 * 310 * @return array|null 311 * An associative array with keys 'where' and 'args' or NULL if there were 312 * no filters set. 315 * @return void changed this line in version 4 of the diff
305 304 * Builds a query for database log administration filters based on session. 306 305 * 306 * This method retrieves the session-based filters from the request and applies 307 * them to the provided query object. If no filters are present, the query is 308 * left unchanged. 309 * 307 310 * @param \Symfony\Component\HttpFoundation\Request $request 308 311 * The request. 312 * @param \Drupal\Core\Database\Query\SelectInterface $query 313 * The database query. 309 314 * 310 * @return array|null 311 * An associative array with keys 'where' and 'args' or NULL if there were 312 * no filters set. 315 * @return void 316 * This method does not return any value. The query object is modified directly. changed this line in version 4 of the diff
325 $where = $args = []; 325 // Build the condition. 326 $condition_and = $query->getConnection()->condition('AND'); 327 $condition_and_used = FALSE; 326 328 foreach ($session_filters as $key => $filter) { 327 $filter_where = []; 329 $condition_or = $query->getConnection()->condition('OR'); 330 $condition_or_used = FALSE; 328 331 foreach ($filter as $value) { 329 $filter_where[] = $filters[$key]['where']; 330 $args[] = $value; 332 if ($key == 'severity') { 333 $value = (int) $value; 334 } 335 if (in_array($value, array_keys($filters[$key]['options']))) { 336 $condition_or->condition($filters[$key]['field'], $value); I think we can optimize the filter conditions. The big question to me is: do we have contrib/custom code that extends the Drupal core functionality? If they do, how will their filters look like. My idea for this change was to change the SQL string condition to one that uses condition objects and try to make the change that we break contrib/custom modules as small as possible. The current SQL conditions use OR conditions. So do you still want to change the OR conditions to conditions with the IN operator? Or is that something for a followup issue? We shall also need to add testing for it.
added 115 commits
-
e6dd7d11...2832459c - 114 commits from branch
project:11.x
- a2e277ca - Merge branch '11.x' into 3476175-change-the-filter
-
e6dd7d11...2832459c - 114 commits from branch
Please register or sign in to reply