Improve views filtering

Created on 12 May 2025, 24 days ago

Problem/Motivation

Currently views integration doesn't support any type of Drupal-side string filtering because it uses the basic string filter which changes filter op code to "LIKE" which isn't supported by the storage client base.

Steps to reproduce

  1. Create an external entity type
  2. Enable Drupal side filtering
  3. Create a view of the new external entity type
  4. Add as string type filter for one of the fields
  5. Try to filter, and no results are shown.

Proposed resolution

Implement the xntt-string filter and pass along the basic Drupal filtering operators so the EE storage client base can handle the filtering

Remaining tasks

User interface changes

API changes

Data model changes

Feature request
Status

Active

Version

3.0

Component

Code

Created by

🇨🇦Canada notkataoka

Live updates comments and jobs are added and updated live.
Sign in to follow issues

Merge Requests

Comments & Activities

  • Issue created by @notkataoka
  • Pipeline finished with Success
    24 days ago
    Total: 258s
    #495201
  • 🇨🇦Canada colan Toronto 🇨🇦

    @notkataoka wrote (but couldn't submit because he's a new user):

    Code might not be quite finished since it just adds the bare minimum to pass the filtering codes to the storage client.

  • 🇨🇦Canada colan Toronto 🇨🇦

    Composer-friendly patch.

  • 🇨🇦Canada colan Toronto 🇨🇦
  • First commit to issue fork.
  • 🇫🇷France guignonv Montpellier

    While the code does not look bad, I could not reproduce the initial problem. However, with no surprise, I tried with a SQL storage client. I need time to try with another client. I'm also wondering if the problem would still be there with "::opNotContains()" "::opNotStartsWith()" and "::opNotEndsWith". I don't have all my ideas clear as it's late but I think the "final" operator is supposed to be provided by the storage clients themselves, so there should be no need for this patch. I need to review that more seriously...

  • 🇫🇷France guignonv Montpellier

    Regarding the xntt_views module code, it needs many improvements and many things are still to be implemented properly. In this case, we use the default filter class provided by the views module except for string because I wanted to add a 'FUZZY' filter to test a custom filter behavior.

    As @notkataoka noticed, the default string filter provided by views works with database strings and uses the 'LIKE' operator and modifies the filter value which is not suitable for other storage back-ends to efficiently manage filtering.

    Filters are passed to the storage clients using StorageClientInterface::transliterateDrupalFilters(). That is where filters can be translated to what is supported by the client when possible.

    There is not an official/standard list of supported operators, but a basic list is provided in the Drupal doc and in XNTT StorageClientBase::testDrupalFilter():
    '=', '!=', '<>', '>', '>=', '<', '<=', 'STARTS_WITH', 'CONTAINS', 'ENDS_WITH', 'IN', 'NOT IN', 'IS NULL', 'IS NOT NULL', 'EXISTS', 'NOT EXISTS', 'BETWEEN' and 'NOT BETWEEN'
    We should list what is used by views to add to this list (eg. "NOT STARTS_WITH").

    StorageClientBase::testDrupalFilter() is used when "standard" filters are not supported by the storage client, to provide a "degraded" filtering support on results. The current implementation does not support properly negated filters (ie. NOT ...). Some are, some aren't. It should be fixed because we can meet "NOT CONTAINS" for instance. The code needs to be refactored to handle "NOT" + any other filter.

Production build 0.71.5 2024