- Can I use klaussilveira/neo4j-ogm-bundle in a Laravel application?
- No. This is a Symfony2 bundle that depends on Symfony kernel and dependency injection conventions, so it will not boot inside a Laravel application. Laravel developers should use the official neo4j/neo4j-php-client behind repository or service classes instead. If you are evaluating Composer packages for Laravel, treat this one as out of scope.
- Which Symfony, PHP, and Neo4j versions does this bundle support?
- It targets legacy Symfony 2.7/2.8 applications on PHP 5.6 or early 7.x with Neo4j 2.x/3.x servers. It assumes Doctrine-style annotations and the OGM's Bolt/HTTP era connectivity. There is no support path for Symfony 5/6/7, PHP 8.1+, or Neo4j 4/5.
- How do I install and register the bundle?
- Installation is via Composer, but it only resolves if your legacy dependency constraints allow the old Symfony and OGM packages. You then register the bundle in AppKernel and add a configuration block defining the Neo4j connection and entity manager settings. There is no Symfony Flex recipe, so all wiring is manual.
- Is this package maintained and safe to use in production?
- Community traction is very low, the underlying Symfony2 stack is end-of-life, and there is no predictable patch cadence. Transitive dependencies such as old annotation and cache libraries carry elevated security and compatibility risk. Treat it as an anti-corruption-layer candidate in a legacy system, not a strategic platform dependency.
- Does the OGM work with Neo4j 4.x or 5.x?
- It is unlikely to work reliably. The OGM layer predates modern Bolt protocol versions and does not cover current routing, transaction, cluster, or async semantics. If you are upgrading from Neo4j 3.x to 4/5, replace the OGM rather than carrying it across the major protocol change.
- What is a good alternative to this bundle for Neo4j in PHP?
- Use the official neo4j/neo4j-php-client and write Cypher directly, mapping results to your own domain objects. Wrap graph access behind repository interfaces so the driver, queries, and mapping can evolve independently. This avoids OGM lock-in and keeps you on a supported protocol version.
- How do I configure entity mapping and repositories with this bundle?
- Entities are mapped with annotations (or attributes) describing nodes, properties, and relationships, and repositories are wired through the Symfony DI container. You define the connection and entity manager in the bundle configuration, then inject repositories into your services. Complex graph patterns and lazy-loading behavior may require hand-written Cypher.
- How should I test entities and repositories built on this OGM?
- Because the OGM generates Cypher and handles metadata parsing and lazy loading, integration tests against a real Neo4j instance of the matching version are more reliable than mocks. Add contract tests around your own repository interfaces so a later swap to the official driver is verifiable. Unit-test domain logic separately from the OGM layer.
- Should I use OGM entity mapping or plain Cypher with the official driver?
- If your domain is graph-centric and you already have annotated entities, the OGM saves boilerplate for mapping and repositories. For new code, plain Cypher behind repository interfaces is usually clearer and performs better on complex traversals. The OGM abstraction also adds coupling that makes future migrations harder.
- How difficult is it to migrate off this bundle later?
- Migrating off a non-standard OGM is harder than starting with the official driver, since mapping, lazy loading, and generated queries leak into domain code. The safest path is to isolate the bundle behind application-owned interfaces and add contract tests now. Then you can replace the OGM with explicit Cypher implementations without rewriting domain logic.