Skip to content
Snippets Groups Projects

Changed the filter functionality to a condition object

Closed daffie requested to merge issue/drupal-3476175:3476175-change-the-filter into 11.x
3 unresolved threads

Closes #3476175

Merge request reports

Loading
Loading

Activity

Filter activity
  • Approvals
  • Assignees & reviewers
  • Comments (from bots)
  • Comments (from users)
  • Commits & branches
  • Edits
  • Labels
  • Lock status
  • Mentions
  • Merge request status
  • Tracking
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
  • 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.
  • daffie added 1 commit

    added 1 commit

    • e6dd7d11 - Removed return void from the docblock

    Compare with previous version

  • 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);
    • Would it be simpler to use IN queries here, rather than build an OR group for each multi-value filter?

    • Author Developer

      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.

    • That seems reasonable

    • Please register or sign in to reply
  • daffie added 115 commits

    added 115 commits

    Compare with previous version

  • closed

  • Please register or sign in to reply
    Loading