- How do I install staudenmeir/laravel-cte in a Laravel app?
- Run composer require staudenmeir/laravel-cte:"^1.0" from your project root. On Windows PowerShell, such as in VS Code, the README shows the caret escaping variant composer require staudenmeir/laravel-cte:"^^^^1.0". There are no service providers to register, migrations to run, or config files to publish. The package version must match your Laravel major, so pick the release listed in the version table.
- Which Laravel versions does staudenmeir/laravel-cte support?
- The package supports Laravel 5.5 and newer, with each package release paired to a Laravel major. Laravel 13 uses package 1.13, Laravel 12 uses 1.12, Laravel 11 uses 1.11, Laravel 10 uses 1.9, Laravel 9 uses 1.6, and older Laravel versions map down to 1.0 for 5.5 through 5.7. Treat the upgrade as a lockstep pairing, because the Composer constraint is bound to the Laravel major rather than being an independent dependency. Add the paired package bump to your Laravel upgrade runbook.
- Which databases does laravel-cte support, and do CTE features differ between them?
- The README lists MySQL 8.0+, MariaDB 10.2+, PostgreSQL 9.4+, SQLite 3.8.3+, SQL Server 2008+, Oracle 9.2+, and SingleStore 8.1+. The feature surface is not uniform: materialization hints are available on PostgreSQL and SQLite only, and native cycle detection requires MariaDB 10.5.2+ or PostgreSQL 14+. On other engines you may need to guard recursion yourself, so check your production and CI database mix before relying on those features.
- How do I write a recursive CTE with Eloquent in Laravel?
- Use withRecursiveExpression on the query builder or Eloquent query and provide a query builder instance, an SQL string, or a closure for the recursive part. The package also documents recursive relationships for Eloquent, so hierarchy-style data such as org charts or category trees can stay in Eloquent rather than PHP-side recursion. This is the main reason to adopt it if you already write DB::raw recursive SQL or walk trees in application code.
- Can I use MATERIALIZED and NOT MATERIALIZED hints with laravel-cte?
- Yes, the package exposes materialized and non-materialized expression variants for CTEs. The important caveat is database support: materialization hints are documented for PostgreSQL and SQLite only. If you run MySQL, MariaDB, SQL Server, Oracle, or SingleStore in production, plan your queries without relying on those hints. This matters most for reporting rollups and other queries where the optimizer may otherwise inline the CTE.
- How does laravel-cte handle cycle detection in recursive queries?
- The package includes cycle detection for recursive expressions. Native cycle detection depends on the database, with MariaDB 10.5.2+ and PostgreSQL 14+ called out as the versions that support it. On engines without native support you must add your own recursion guards, such as depth limits or visited-path checks. Test this against the exact database and version you deploy, not just against SQLite in local development.
- Does laravel-cte support INSERT, UPDATE, and DELETE queries with CTEs?
- Yes, the package adds CTE support to INSERT, UPDATE, and DELETE queries in addition to SELECT. That lets you reuse a common table expression for data-changing statements without dropping back to raw SQL. As with SELECT queries, confirm the syntax works on every database engine you target. This is useful for bulk updates driven by hierarchy or graph traversal results.
- Does laravel-cte work with Lumen or Oracle?
- Both have documented caveats. Lumen and Oracle require manually instantiating Staudenmeir\LaravelCte\Query\Builder or OracleBuilder rather than relying on the normal facade path. CTE queries written against the Laravel DB facade will not simply work on those paths. If Oracle or Lumen is anywhere on your roadmap, budget for that manual wiring and test it before adoption.
- Will laravel-cte conflict with packages that customize Laravel's query builder or connection factory?
- That is the make-or-break compatibility check. The package works by substituting its own connection factory plus CTE-aware query builder and grammar classes into Laravel's database layer, which is a global interception of the DB stack. Any installed package or in-house code that supplies a custom query builder, tenancy hook, or read/write split touching the connection factory must be verified against it. The changelog shows past compatibility fixes for exactly this, including grammar-selection fixes in 1.12.3.
- Is staudenmeir/laravel-cte actively maintained, and what are the alternatives?
- The project has CI, code coverage, PHPStan level 10, and an active release history through early 2026, but it is a single-maintainer package with a zero reported dependent count. Release timing has trailed Laravel majors by weeks, and Firebird support was dropped in 1.13. Alternatives are raw recursive SQL through DB::raw, PHP-side tree walks, or dedicated nested-set and adjacency-list packages, but those either keep the traversal code you wanted to delete or add a different abstraction. If you accept single-maintainer risk for a component in the DB layer, define a fork or contingency posture up front.