Problem/Motivation
The Select query builder allows setting a range using:
$query->range($start, $length);However, there is currently no public API to retrieve the configured range values from the query object after they have been set.
This makes it difficult for modules and integrations to inspect an existing query and determine:
- Whether a range has already been applied
- What the
start(offset) value is - What the
length(limit) value is
This limitation affects use cases such as:
hook_query_alter()implementations that need to adjust or respect existing pagination- Query decorators or wrappers that must preserve previously defined ranges
- Contrib modules extending or modifying queries before execution
- Debugging or logging tools requiring full visibility into query configuration
Proposed resolution
Introduce a public getter method on Select query objects to expose range information.
For example:
$range = $query->getRange();Suggested behavior:
- Return
NULLif no range is set - Return an associative array if defined:
[ 'start' => $start, 'length' => $length, ]Alternatively, the API could provide:
hasRange()getRange()
This maintains encapsulation while allowing safe and supported introspection of query state.
Alternatives considered
- Accessing internal properties directly (not acceptable; violates encapsulation)
- Requiring modules to track range values separately (adds unnecessary complexity)
- Leaving the API unchanged and discouraging introspection (limits extensibility)
Remaining tasks
- Decide on final method naming and return structure
- Add unit test coverage
- Update inline documentation
- Verify no backward compatibility concerns
API changes
Yes — adds a new public method to Select.
The change is backward compatible.
| Comment | File | Size | Author |
|---|---|---|---|
| #4 | 2986699-4--getRange.patch | 1.99 KB | drunken monkey |
Issue fork drupal-2986699
Show commands
Start within a Git clone of the project using the version control instructions.
Or, if you do not have SSH keys set up on git.drupalcode.org:
- 2986699-no-way-to
changes, plain diff MR !14810
Comments
Comment #2
drunken monkeyThis would add the getter.
Comment #4
drunken monkeyAh, right!
Comment #5
borisson_Good catch, probably this will need some kind of test to ensure that this behavior works? A kernel-test would be the perfect place for this. I can't see any kind of test for ranges in
core/tests/Drupal/Tests/Core/Databasewhich is where this should probably end up.Since there is no test for ranges currently, we could probably get away with not adding a test and doing that in a followup instead.
Comment #6
daffie commentedComment #15
luke.stewart commentedThis is the Bug Smash Initiatives target today.
I've verified that this feature is not present in latest drupal codebase
In https://git.drupalcode.org/project/drupal/-/blob/main/core/lib/Drupal/Co... or
https://git.drupalcode.org/project/drupal/-/blob/main/core/lib/Drupal/Co...
I'm not sure if this should perhaps be reclassified as a Feature request.
Looks like all that is required here would be some testing.
Note based on the documentation of the other getters the comment could probably do with updating to match the same style.
Comment #17
sivaji_ganesh_jojodae commentedComment #19
neptune-dc commentedBuilt the fork and added two Kernal tests. Everything is running green. I tested locally with these commands:
PHPSTAN:
ddev exec vendor/bin/phpstan analyse \
-c core/phpstan.neon.dist \
core/tests/Drupal/KernelTests/Core/Database/SelectGetRangeTest.php
PHPCS:
ddev exec vendor/bin/phpcs --standard=Drupal core/tests/Drupal/KernelTests/Core/Database/SelectGetRangeTest.php
PHPCBF:
ddev exec vendor/bin/phpcbf --standard=Drupal core/tests/Drupal/KernelTests/Core/Database/SelectGetRangeTest.php
Run test:
ddev exec bash -c '
export SIMPLETEST_DB="mysql://db:db@db/db"
export SIMPLETEST_BASE_URL="http://web"
export BROWSERTEST_OUTPUT_DIRECTORY="sites/simpletest/browser_output"
mkdir -p sites/simpletest/browser_output
chmod -R a+w sites/simpletest
vendor/bin/phpunit -c core/phpunit.xml.dist core/tests/Drupal/KernelTests/Core/Database/SelectGetRangeTest.php
'
Comment #20
luke.stewart commentedThanks for your work on this. Great work updating issue summary.
I'm flipping back to Needs Work as I think this will probably need a change record?
>Yes — adds a new public method to Select.
https://www.drupal.org/about/core/policies/core-change-policies/change-r... -> An API change
I also wonder if we need to ensure the documentation is consistent across the methods in the Select Interface.
namely:
compare these lines:
Comment #21
neptune-dc commentedI have added a change record. It is my first time, so I would appreciate someone to review it.
https://www.drupal.org/node/3574425
Comment #22
borisson_The change record looks great
Comment #23
drunken monkeyI had one minor comment, but otherwise looks good to me. Could be RTBC if someone agrees with my change.
Comment #24
borisson_I agree.
Comment #25
quietone commentedWhile checking change records I saw that the one here was published although the issue has not been committed. So, I have returned it to a draft state. Also, the version and branch are incorrect and should be updated.
Comment #26
drunken monkeyFixed the typo pointed out by @sivaji_ganesh_jojodae.
I also think that even though the rest of the methods in the interface don’t have type hints the new method should get one? Added that, too, please feel free to revert.
Comment #27
drunken monkey@quietone What is the correct version for the change record, 12.0.0?
In any case, I also found an error in the text, it claims the method returns
NULL(instead of[]) if there is no range set. However, we might also want to adapt the code to match the change record instead? To me personally,NULLmakes much more sense than[].Comment #28
neptune-dc commented> Return NULL if no range is set
Updated the function to return null when no range is set. This is following instructions in the summary.
Comment #30
smustgrave commentedBelieve CR matches the solution. Did update branch for main as this is an API change that not sure which 11.x branch will land in
Test coverage can be seen here https://git.drupalcode.org/issue/drupal-2986699/-/jobs/9031886
Did rebase to trigger a new pipeline that I can rerun as a Reporter role.
Took a crack at credit while I was at it. Believe this one is good to go.
Comment #31
catchCommitted/pushed to main and 11.x, thanks!