Weave Code
Postgres Bundle Laravel Package
1tomany/postgres-bundle
Doctrine Postgres Bundle for Symfony adds Postgres enhancements for Doctrine: an advisory lock manager and time zone middleware, auto-configured for your default DBAL connection and customizable via YAML.
Doctrine Postgres Bundle extends Doctrine for Symfony applications with Postgres-specific capabilities. It auto-configures against the default Doctrine DBAL connection, and you can fine-tune it through config/packages/onetomany_postgres.yaml.
- Advisory lock manager for coordinating work across processes
- Time zone middleware that normalizes connections to a configured zone
- Sensible defaults — works out of the box with your existing DBAL connection
- Simple YAML configuration for the lock connection and time zone
- Symfony bundle integration with minimal setup
Frequently asked questions about Postgres Bundle
- Is 1tomany/postgres-bundle a Laravel package?
- No. It is a Symfony bundle that enhances PostgreSQL support for Doctrine, so it is not a native Laravel or Eloquent package. You can only use it in Laravel through a Doctrine ORM integration such as spatie/laravel-doctrine-orm, and you will need to adapt its Symfony-style configuration.
- How do I install 1tomany/postgres-bundle for a Laravel app using Doctrine?
- Install it with Composer by running composer require 1tomany/postgres-bundle. In a Symfony app the bundle auto-configures against the default Doctrine DBAL connection, but a Laravel app needs Doctrine ORM plus manual service or bundle wiring. Plan to translate the onetomany_postgres.yaml settings into your Laravel Doctrine configuration.
- What advisory lock features does the bundle add to Doctrine?
- It provides an AdvisoryLockManager with configurable PostgreSQL advisory locking, including session-scoped locks and transaction-scoped locks added in v0.0.11. It supports iterative lock release for multi-step workflows and composite lock names such as user:123:profile. The manager is designed to work with the default DBAL connection unless you configure another one.
- When should I use a transaction-level advisory lock instead of a session-level lock?
- Use a transaction-level lock when the critical section must stay inside one database transaction and should auto-release on COMMIT or ROLLBACK. Use a session-level lock when the guarded workflow spans multiple commits, such as a saga or long-running orchestration. Do not mix session and transaction locks on the same key without understanding which lifecycle you need.
- How do I configure the advisory lock manager and time zone middleware?
- The bundle auto-configures with the default Doctrine DBAL connection. To override it, create config/packages/onetomany_postgres.yaml and set advisory_lock_manager.connection plus middleware.time_zone, for example UTC. In Laravel you must adapt this YAML structure to your Doctrine integration rather than expecting Symfony package auto-discovery.
- Is the bundle maintained and which Laravel versions does it support?
- It is a Symfony/Doctrine package, not a Laravel-versioned package, so there is no direct Laravel 10 or Laravel 11 support matrix. Its compatibility depends on its Symfony, Doctrine DBAL, PHP, and PostgreSQL constraints plus your Laravel Doctrine bridge. Check the GitHub releases and Packagist metadata for current maintenance activity before adopting it.
- What production risks should I watch for with iterative advisory lock release?
- Inconsistent lock ordering can cause deadlocks, especially with composite keys such as A:B and B:A. Session-level locks can leak if segment tracking or release logic fails, while transaction-level locks self-heal at transaction end. Long transactions hold transaction locks longer than intended and can increase contention. Define a consistent lock key order and test rollback paths before production.
- Can I use 1tomany/postgres-bundle with Laravel Eloquent?
- No. The bundle enhances Doctrine DBAL and ORM, and Eloquent does not use Doctrine's connection by default. Using it with Laravel requires Doctrine ORM integration and manual wiring of the advisory lock manager. If your application is Eloquent-only, native PostgreSQL advisory locks or a Laravel locking package is a better fit.
- How should I test transaction-scoped advisory locks in Laravel?
- Run integration tests against PostgreSQL, not SQLite, inside an actual transaction or DB::transaction call. Verify that the lock is acquired, that competing transactions block as expected, and that COMMIT and ROLLBACK release the lock automatically. Avoid calling unlockPartial inside a pg_advisory_xact_lock-protected transaction because that behavior is unsafe or undefined. Also test nested transaction and savepoint behavior for your Doctrine setup.
- What are alternatives to this bundle for PostgreSQL locking in Laravel?
- Alternatives include Redis or database-backed Laravel locks, the Symfony Lock component, and direct PostgreSQL advisory lock calls through DB::select. This bundle is a good fit when you already use Doctrine with PostgreSQL and want lock management plus timezone middleware without adding Redis. Compare operational complexity, lock lifetime semantics, and deadlock handling before choosing.
Weaver
How can I help you explore Laravel packages today?