Filter eager-loaded releases by requires constraint#47
Open
Conversation
When the requires filter is active, only releases matching the version constraint are now included in the response. Previously, all releases were returned even when the package was filtered by requires version, because the constraint only applied to package selection (whereExists) but not to the eager-loaded releases relation. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com> Signed-off-by: Joost de Valk <joost@altha.nl>
SvenLie
approved these changes
Mar 21, 2026
|
When I'm searching for a TYPO3 version without existing releases for it, I get all releases again. Search for version 14.2:
I not want to get releases < 14.2. I would expect to get releases which minimum support TYPO3 version 14.2 or higher. But I think we need to respect version constraints (see comment below) |
|
Also I think we should be able to search within a range. For example we often have version constraints like: How can we do that properly? |
Replace SQL integer array comparison with Composer\Semver\Semver::satisfies() to properly evaluate version constraints like ">=11.5.19 <=12.9.99", "^12.4", and "~12.4". The old approach only handled plain version numbers and could not parse range constraints, causing incorrect matches or failures. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com> Signed-off-by: Joost de Valk <joost@altha.nl>
The Contracts interface doesn't declare getCollection(), but the concrete Illuminate\Pagination\LengthAwarePaginator does. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com> Signed-off-by: Joost de Valk <joost@altha.nl>
|
Works now perfect. Thank you |
The requires JSONB stores keys like "env:typo3" and "env:php", not plain "typo3"/"php". Update factory and tests to match. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com> Signed-off-by: Joost de Valk <joost@altha.nl>
Add GIN index on package_releases.requires JSONB for fast key-existence checks. Scope the candidate query to the current package type via a join on packages.type, reducing the result set before PHP-side Semver matching. Use jsonb_exists() which leverages the GIN index. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com> Signed-off-by: Joost de Valk <joost@altha.nl>
Instead of loading all releases into PHP and running Semver::satisfies() on each (thousands of calls causing 30s timeout), collect the distinct constraint strings per key (typically 20-50 values), run Semver on those few, then use SQL IN() to find matching package IDs. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com> Signed-off-by: Joost de Valk <joost@altha.nl>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Replaces the SQL-based integer array version comparison with proper Composer semver constraint matching using
composer/semver. This fixes two issues raised in review:?requires[typo3]=14.2against a package with constraint>=11.5.19 <=12.9.99would incorrectly match, because the old SQLstring_to_array()::int[]comparison could not parse range constraints.>=11.5.19 <=12.9.99,^12.4,~11.5, not plain version numbers. These are now evaluated correctly.How it works
applyRequiresFilteruses SQL to narrow candidates to releases that have the required keys in theirrequiresJSONB, then evaluates constraints in PHP viaSemver::satisfies()to collect matching package IDs.filterPaginatedReleasespost-filters eager-loaded releases on paginated results so only compatible releases appear in the response.composer/semver(already a transitive dependency) is now an explicit require.Use case examples
Find extensions compatible with TYPO3 12.4:
A package with
"typo3": ">=11.5.19 <=12.9.99"-> matches (12.4 is in range)A package with
"typo3": ">=13.4.0 <=13.99.99"-> excluded (12.4 is below range)Search for a gallery extension compatible with TYPO3 13.4 and PHP 8.2:
Only returns packages named like "gallery" that have at least one release where both constraints are satisfied. Only those matching releases are included in the response.
Constraint formats supported (anything
composer/semverhandles):>=11.5.19 <=12.9.99^12.4~12.4>=13.012.4.0Test plan
php artisan test --filter=PackageSearchControllerTestand confirm all tests passGET /packages/typo3-extension?requires[typo3]=14.2returns no packages when all extensions require<=12.9.99GET /packages/typo3-extension?requires[typo3]=12.4returns only releases whose constraint includes 12.4requiresstill return all releases unchangedGenerated with Claude Code