- Is pvsaintpe/ltree-bundle compatible with Laravel?
- Not directly. The package is a Symfony bundle built around Doctrine DBAL custom types, Doctrine schema helpers, and Symfony service wiring, so there is no Eloquent integration, no service provider, and no Laravel-native cast. Its last release dates to March 2021, which implies PHP 7.x, Doctrine DBAL 2.x, and Symfony 4/5-era constraints that will likely fail Composer resolution on Laravel 10 or 11. Treat it as a reference implementation and SQL contract rather than a dependency you install.
- What does pvsaintpe/ltree-bundle actually do for hierarchical data?
- It wraps PostgreSQL's ltree contrib extension so tree structures such as categories, org charts, comment threads, and taxonomies are stored as dot-delimited materialized paths. That lets you filter ancestors and descendants with the @> and <@ operators and GiST indexes instead of recursive CTEs. The bundle contributes a Doctrine ltree type, schema and migration helpers to enable the extension and create indexes, and path-manipulation services.
- Can I use PostgreSQL ltree with Laravel Eloquent without this package?
- Yes, and that is usually the right call. Run a raw migration with CREATE EXTENSION IF NOT EXISTS ltree, add a path ltree column, and create a GiST index on it. Then add an Eloquent cast or accessor for the path and query scopes that emit whereRaw clauses using @> and <@. You own roughly a day or two of code, but it stays on your supported DBAL and PHP versions.
- How do I create the ltree extension and GiST index in a Laravel migration?
- Use DB::statement inside an up() method for the extension, since Laravel's schema builder has no ltree column type. Add the column with a raw ALTER TABLE or a string column you convert, then create the index with CREATE INDEX ... USING GIST (path). Keep the statements idempotent with IF NOT EXISTS so repeated deploys and fresh test databases behave the same. Note that CREATE EXTENSION requires privileges that some locked-down managed Postgres services block.
- How do I write descendantsOf and ancestorsOf scopes for ltree in Eloquent?
- Add local scopes that build whereRaw conditions against the ltree column, using the @> operator for descendants and <@ for ancestors, binding the subject path as a parameter rather than interpolating it. An atDepth scope can compare against subpath or nlevel depending on your storage conventions. Include a GiST index so these predicates stay fast, and assert the generated query plan in a test to confirm the index is used.
- How do I migrate existing parent_id data to an ltree path column?
- Backfill the path column from your existing parent_id hierarchy with a recursive CTE, building each path as dot-delimited labels from the root down. Keep parent_id as the source of truth at first, derive the path in model observers or a job, and dual-write until you can verify parity in tests. Cut read queries over to the ltree operators only after parity holds, and retain parent_id for referential integrity and joins.
- How do I move or delete a subtree safely with ltree?
- A subtree move requires rewriting the path of every descendant row, which is O(subtree size), so wrap the operation in a transaction and test it explicitly. The original bundle offers no guarantee of transactional handling for moves, so implement the update yourself with a single UPDATE using the ltree functions or a prefix replacement. Verify with tests that cover concurrent reads, deep trees, and rollback on failure.
- What are the limitations of ltree labels and path depth?
- ltree labels are restricted to alphanumerics and underscores, with dots as delimiters, so slugs with hyphens, spaces, or unicode need sanitizing or a separate identifier column. The package does not guarantee label sanitization or a path depth cap, which means that responsibility falls to your application code. Very deep paths also inflate index size, so cap depth deliberately.
- Should I adopt this bundle if I am not using PostgreSQL?
- No. The entire value proposition depends on the ltree extension, which is PostgreSQL-only, so it is meaningless in MySQL, MariaDB, or SQLite-backed estates. Even in polyglot setups where Postgres is one of several stores, you would be adding a database-specific hierarchy model that other services cannot share. Reject it for multi-database products and MySQL shops.
- Is pvsaintpe/ltree-bundle maintained, and what are the alternatives?
- Effectively unmaintained since March 2021, with a single maintainer and around ten stars, so assume full ownership if you depend on it. Alternatives are to fork it under your organization, vendor only the SQL patterns and operator semantics, or skip the dependency entirely and implement ltree directly in Laravel migrations and Eloquent scopes. Check the repository for the declared license before forking, and confirm whether any active community fork exists.