Frequently asked questions about Eloquent Param Limit Fix X Laravel Adjacency List
- What does staudenmeir/eloquent-param-limit-fix-x-laravel-adjacency-list actually do?
- It is a compatibility bridge, an "x" metapackage, between staudenmeir/laravel-adjacency-list and staudenmeir/eloquent-param-limit-fix. Adjacency list builds recursive CTE queries through a custom query-builder path that bypasses the parameter-chunking traits, so deep or wide trees can exceed driver placeholder ceilings. The bridge restores that integration so large binding sets are chunked automatically. It adds no features of its own beyond making the two packages coexist.
- How do I install it with Composer?
- Run composer require staudenmeir/eloquent-param-limit-fix-x-laravel-adjacency-list and let Composer resolve the bridge plus both parent packages. There is no service provider, publishable config, migration, or asset to install. Check the resolved versions of all three packages in composer.lock rather than relying on release notes, and pin constraints deliberately.
- Do I have to change my models to use it?
- Yes, but minimally. On each hierarchical model, replace the HasAdjacencyList trait from laravel-adjacency-list with the trait exported by this bridge package. That swap is essentially the entire integration surface. No configuration or schema changes are required.
- Do I need this package if I use MySQL or PostgreSQL?
- Only if your trees are wide or deep enough to approach those drivers' much higher parameter ceilings. It is effectively required on SQLite, where the limit is around 999 bind parameters, and on SQL Server, where it is 2,100. If you are not on a constrained driver and your query sizes stay modest, the bridge is unnecessary weight in your dependency graph.
- Which Laravel and PHP versions are supported?
- The v1.4 release widens the framework constraint to support Laravel 13, following on from v1.3. Bridge versions do not map one-to-one with Laravel majors, so treat this as a version matrix spanning the bridge, both parent packages, Laravel, and PHP. Confirm the constraints in composer.json and lockfile before upgrading Laravel. The v1.4 change is additive with no API, config, or migration changes.
- What errors does this package prevent?
- It prevents placeholder-limit failures such as SQLite's "too many SQL variables" around 999 bind parameters and SQL Server's 2,100-parameter error. These surface when recursive adjacency-list queries generate large whereIn or binding sets. The underlying fix chunks those binding sets transparently so the query stays under the driver ceiling. Without the bridge, adjacency list's custom query path skips that chunking.
- Does it change my database schema or query results?
- No, it ships no migrations and does not alter your schema. The parameter-limit fix chunks large binding sets, so results should be identical; it changes how queries are executed, not what they return. Still run your own tree-query regression suite, since correctness is inherited from the upstream packages.
- Can I use it alongside other staudenmeir packages?
- Be careful. The package name encodes exactly two parents, and introducing a third staudenmeir package can make dependency resolution unsatisfiable. Constrain your dependency graph deliberately and test resolution in CI. If your organization has standardized on nested sets or closure tables instead, this package should not appear in the graph at all.
- Is this package well maintained, and what is the bus factor?
- A single author maintains all three packages, so bus factor is effectively one across the whole family. Star count and dependent count are low, which is not a quality signal for a bridge this narrow but does mean thin community validation of edge cases. Mitigation is cheap: the shim is roughly a one-class fork, but document that fallback before you need it rather than improvising during an incident.
- How should I test and verify the integration?
- Exercise deep and wide hierarchy queries against SQLite in CI, where the ~999 parameter limit triggers the failure mode most reliably. Run that suite after every Laravel upgrade and after any change to the bridge, adjacency list, or param-limit-fix versions. Verify the actual resolved versions in the lockfile, not the release notes. A passing tree-query regression pass is the real safety net for this package.