- What is staudenmeir/eloquent-eager-limit-x-laravel-adjacency-list used for?
- It is a compatibility bridge that merges staudenmeir/eloquent-eager-limit with staudenmeir/laravel-adjacency-list so the two work together. It lets you apply limit() to eager-loaded relations on recursive adjacency list models, producing a per-parent LIMIT via ROW_NUMBER() OVER (PARTITION BY ...). Typical uses are latest N replies per thread, a few featured children per category, capped reporting lines, and two- or three-level menu previews.
- How do I install and use the package in a Laravel app?
- Install it with Composer using the package name staudenmeir/eloquent-eager-limit-x-laravel-adjacency-list. Add the provided trait to the target hierarchy model and use standard eager-load closures with limit() on the relation. There is no schema migration, backfill, or dual-write involved; the change is additive code in one model or bounded context.
- Does this package support Laravel 11 and Laravel 12?
- That is not proven by the package metadata. The last release shown is 2023-05-14, so Laravel 11 and 12 support must be confirmed by reading composer.json for the bridge and both upstream packages rather than trusting the README. Pin the versions and run your test suite before committing to a framework upgrade.
- Which databases does this package require?
- The underlying per-parent limit relies on window functions, so you need MySQL 8 or newer, PostgreSQL, SQLite 3.25 or newer, or SQL Server. MySQL 5.7 and MariaDB are not viable for this approach. Confirm your engine and version before speccing the feature, because the requirement is non-negotiable.
- Does limit() work with recursive relationships at depth 2 or deeper?
- That is the main unknown to validate in a spike. The package is intended for recursive adjacency list relationships, but the practical depth ceiling is not documented, so test depth 2, 3, and beyond with realistic data. Record the results and treat any depth limitation as a design constraint.
- How does this package help avoid N+1 queries?
- Eager loading normally fetches every related record for every parent, and lazy loading issues a query per parent. This package caps the eager load per parent inside the query using a partitioned window function, so you get a bounded set with a single query shape. That matters for presentational reads on hubs or threads with many children.
- Will global scopes, soft deletes, and multi-tenancy filters still apply?
- This is a medium, silent risk because relationship traits intervene in query resolution. Global scopes, soft delete constraints, and tenancy predicates on traversed records are the most likely place for wrong-but-plausible results rather than errors. Inspect the generated SQL and add tests that assert scope behaviour across the hierarchy before relying on it.
- What is the performance impact of the generated query?
- A recursive CTE plus a window function plus a limit is a heavyweight query. It is correct by construction, but performance depends heavily on data shape, and hub nodes and deep trees are where it degrades; uniform test data will flatter it. Run EXPLAIN, confirm index usage on the parent column, and benchmark against production-like data.
- When should I avoid this package and what are the alternatives?
- Skip it if your hierarchy is a nested set, closure table, or materialized path, or if the hierarchy has not been modelled yet; the package only fits adjacency lists with a parent_id column. Also skip it if the read is not bounded and presentational, or if your database lacks window functions. In those cases use the appropriate hierarchical model or a hand-written query instead.
- Is this package safe to use in production and how hard is rollback?
- It has 14 stars, zero dependents, one maintainer, a pre-2.0 version, and no SLA or security policy, and the last release was 2023-05-14, so treat maintenance as a real risk. The author is a well-known Laravel contributor, which improves the bus factor, but there is no commercial backing and you may need to read source for behaviour questions. Rollback is easy because traits are additive: remove the trait and revert the deploy, with no data project involved, provided you keep the old query path alive behind a repository method or scope.