- What is doctrine/phpcr-odm used for?
- It is a Doctrine-style object-document mapper for PHPCR content repositories, giving PHP objects transparent persistence through a DocumentManager, unit of work, identity map, metadata drivers, and repositories. It is designed for hierarchical, versioned content such as page trees, taxonomy nodes, asset folders, and translated content. It is not an Eloquent-compatible ORM or a general replacement for Laravel's database layer.
- Does doctrine/phpcr-odm support Laravel?
- The library is framework-agnostic and installable with Composer, but there is no first-party Laravel package. In Laravel you would own a service-provider shim plus configuration for the DocumentManager, metadata driver, PSR-6 cache, event manager, and a concrete phpcr/phpcr-implementation. The documented integration path in the Doctrine ecosystem is the Symfony bundle, so Laravel support is custom integration work rather than a supported adapter.
- How do I install doctrine/phpcr-odm in a Laravel project?
- Install the ODM with Composer and also require a PHPCR implementation such as jackalope/jackalope-jackrabbit or jackalope/jackalope-doctrine-dbal. The ODM alone does not provide storage; you must configure the backend connection, repository, metadata paths, cache, and event manager in a Laravel service provider. Expect this to be a spike-level integration, not a single composer require.
- What backend does doctrine/phpcr-odm require?
- It requires a phpcr/phpcr-implementation, with the common options being Jackalope on Jackrabbit or Jackalope on Doctrine DBAL. Jackrabbit means operating a JVM service, while DBAL means provisioning and migrating a SQL schema that stores the content repository. The backend choice drives your operations, scaling, backup, and upgrade work.
- When should I use PHPCR ODM instead of Eloquent?
- Use it only when the bounded domain is materially hierarchical and content-shaped, with real needs for subtree traversal, node moves, references, workspaces, or versioned drafts. It is a poor fit for mainstream CRUD and transactional Laravel domains where Eloquent is already well understood. Frame the decision as adopting a second persistence paradigm for one content domain, not changing the application's data layer.
- Does doctrine/phpcr-odm support versioning and hierarchical content?
- Yes, PHPCR is built around a tree of nodes and supports hierarchical traversal, moves, references, and versioning semantics that the ODM exposes through its document mapping. That is the main reason to consider it for page trees, category hierarchies, asset folders, and translated or versioned content. You still need to validate that the chosen backend and your content model use those capabilities correctly.
- How do I test doctrine/phpcr-odm in a Laravel app?
- The upstream project has separate test setups for the doctrine-dbal and Jackrabbit implementations, including scripts to initialize storage and PHPUnit configuration files. For Laravel, keep the PHPCR adapter behind an internal content-repository interface so most tests can use an in-memory or fake implementation. Reserve integration tests for the adapter and run them against the same backend family you deploy.
- What are the production risks of doctrine/phpcr-odm?
- The main risks are ecosystem and operations, not just code: the project has a small community footprint, no downstream dependents in the referenced assessment, and no first-party Laravel integration. You must operate either a JVM-based Jackrabbit service or a DBAL-backed SQL schema, and you own health checks, backups, migrations, and lifecycle wiring. Plan for recurring upgrade work because recent major lines have included BC breaks.
- Is doctrine/phpcr-odm maintained and which version should I pin?
- The project is maintained and current, with the 2.x line tracking recent Symfony and PHP versions and 3.0.0 moving to Doctrine Persistence 4. It is not abandoned, but the upgrade history includes annotations removed for attributes, Doctrine Cache replaced by PSR-6, DocumentManager interface changes, and removed methods such as merge. Pin a major version deliberately and assign ownership for the recurring upgrade line item.
- How do I isolate doctrine/phpcr-odm so I can replace it later?
- Define an internal content-repository port for the operations you actually need, such as page-tree, taxonomy, and asset-folder behavior. Let application code depend on that interface and keep DocumentManager, Node, Path, and PHPCR-specific types inside one thin adapter. This containment limits exit cost and makes it possible to swap the PHPCR backend or persistence approach without rewriting domain code.