- What does staudenmeir/eloquent-eager-limit-x-laravel-cte actually do?
- It is a merge of staudenmeir/eloquent-eager-limit and staudenmeir/laravel-cte, letting you use common table expressions and per-parent eager load limits in the same Eloquent query. Eager limit loading compiles a per-parent LIMIT into ROW_NUMBER() OVER (PARTITION BY ...), while the CTE package adds WITH and WITH RECURSIVE support to the query builder. The package exists because both upstream packages override Laravel's SQL compilation path and produce malformed SQL when combined. It is a compatibility shim rather than a new capability.
- How do I install staudenmeir/eloquent-eager-limit-x-laravel-cte?
- Install it with Composer using composer require staudenmeir/eloquent-eager-limit-x-laravel-cte. Integration follows the idiom of the two upstream packages: you apply the provided traits to your models and relations. There is no service provider, no migration, and no background process to configure, so the architectural surface is small.
- Which Laravel and PHP versions does this package support?
- The last tagged release is from February 2023, which places it in the Laravel 9 and Laravel 10 window. Laravel 11 and 12 changed grammar and relation internals, and a package whose entire value is overriding protected compilation behaviour is exactly what breaks on a major bump. Treat the published version constraint as a starting point only and prove compatibility with a spike on your target Laravel and PHP versions.
- Do I need this merge package if I only use eager limits or only use CTEs?
- No. If your query shape needs only per-parent eager loading, take staudenmeir/eloquent-eager-limit directly; if it needs only common table expressions or recursive querying, take staudenmeir/laravel-cte. This package is justified only where a single query needs both behaviours at once. Confirming that requirement is real rather than speculative should be the first question you answer.
- What database versions are required for CTEs and window functions?
- CTEs and window functions need MySQL 8.0 or later, PostgreSQL, SQLite 3.25 or later, or SQL Server. A MySQL 5.7 estate is disqualified outright, which turns adoption into a hosting and upgrade roadmap decision with cost and migration risk attached. Check your production database and version before evaluating anything else.
- How do I limit eager loaded relationships per parent model using a CTE?
- Apply the package traits to the model and the relationship, define your common table expression through the query builder, then constrain the eager load with a limit as you normally would. The package compiles the per-parent limit into a partitioned row number so each parent gets its own top N related rows. Keep the relationship definition and the partition key explicit in one place so the generated SQL stays auditable.
- Is this package still maintained and safe to use in production?
- It has a single maintainer, around six stars, zero dependents, and no release in over two years, so there is no production user base to discover breakage ahead of you. That makes abandonment risk high and means you would be the canary for any Laravel upgrade. If you adopt it, budget for a vendored fork and name an owner before you ship.
- Can I use latestOfMany(), ofMany(), or a subquery instead?
- For many cases yes, and that is the cheapest possible outcome, so rule it out first. Native options include latestOfMany() and ofMany() for single related records, a whereIn subquery, or a precomputed summary table for feed and reporting surfaces. Only reach for this package when you genuinely need both CTEs and top-N-per-parent limits in one statement.
- How do I test that per-parent eager limits return the correct rows?
- Per-parent limiting is only as correct as the PARTITION BY key, and a wrong partition returns plausible-looking wrong data instead of an error. Write tests with several parents that have different related record counts, then assert both the number of related rows per parent and their ordering. This failure class survives QA and surfaces as a business-data dispute, so cover it explicitly rather than relying on smoke tests.
- What are the alternatives and the blast radius if this package breaks?
- The blast radius is favourable: the package only generates SQL at compile time, with no persistence, queue, external I/O, or runtime state, so failure shows up as a broken or wrong query on a bounded set of endpoints. Alternatives are taking the two upstream packages separately where only one behaviour is needed, replacing the query with a native subquery, or moving the reporting path to a dedicated read model. Because a merge package signals that two advanced builder extensions collide on the same path, treat that as a design conversation worth having while the surface is still small.