- Can I use garak/doctrine-postgres-types-bundle in a Laravel application?
- No. It is a Symfony bundle that relies on Symfony's dependency injection container and bundle auto-registration to wire Doctrine DBAL types, so it contributes nothing to Eloquent or Laravel's query builder. If you are on Postgres with Eloquent, use native casts such as array, AsArrayObject, and AsCollection alongside $table->jsonb() column definitions, or write a small custom cast class. The bundle is only worth mining as a reference for its type-conversion logic.
- How do I install and register this bundle in a Symfony project?
- Run composer require garak/doctrine-postgres-types-bundle, then register the bundle in config/bundles.php. Confirm your doctrine/dbal connection is configured for PostgreSQL, then run doctrine:schema:validate or doctrine:migrations:diff to check that your entity mappings resolve. The types themselves are registered either through a compiler pass, doctrine.dbal.types configuration, or both, so check src/ for the exact mechanism before assuming it is automatic.
- Which PostgreSQL column types does this bundle actually map?
- The bundle targets PostgreSQL-native types that Doctrine DBAL does not handle out of the box: jsonb, arrays, hstore, inet and cidr, range types, and ltree among others. The exact supported set has to be confirmed against src/, since the README does not enumerate every class. Check whether the version you install covers the specific columns your schema uses before committing to it.
- Is this package actively maintained and safe for production use?
- Treat it as an unmaintained personal artifact: roughly 3 GitHub stars, zero dependents, and a low aggregate score. Assume no security response, no CVE monitoring, and no upstream fixes, which is a real risk for anything in the persistence layer. If you adopt it, vendor-fork it under your own organisation, pin the version, and own the maintenance yourself.
- What PHP, Doctrine DBAL, and Symfony versions does it support?
- There is no Laravel version support to speak of because the package is Symfony-only, but you still need to check composer.json for its php, doctrine/dbal, and symfony/* constraints against your locked versions. The codebase predates recent Doctrine changes, so verify it against PHP 8.3 and 8.4 and the Symfony 6 or 7 bundle metadata. A mismatch here is the most likely cause of a failed install or a silent runtime break.
- How does it compare to martin-georgiev/postgresql-for-doctrine?
- martin-georgiev/postgresql-for-doctrine covers largely the same gap, with active releases and real download volume behind it. The garak bundle's only durable value is the compiler-pass registration convenience, which is a handful of lines to write yourself. For anything going into production, the maintained alternative is the safer starting point.
- What are the licensing implications of LGPL-3.0 for a Composer dependency?
- LGPL-3.0 is generally workable for an unmodified Composer dependency, functioning like the dynamic-linking case in compiled software. It still imposes notice and relink obligations, and it will trip automated license scanners in regulated or commercially licensed distribution scenarios. Whether you ship a SaaS product or a shipped appliance changes the analysis, so this needs a legal sign-off rather than an engineering judgement, and that also applies to copying code out of the repository.
- Will it keep working after upgrading to Doctrine DBAL 4 or Symfony 7?
- That is unverified and is the single biggest technical risk. Doctrine DBAL 3 deprecated Type::addType() in favour of doctrine.dbal.types configuration, and DBAL 4 moved further to a TypeRegistry, so a compiler pass written for DBAL 2 or 3 is a plausible hard break. Confirm whether the bundle registers via compiler pass, config, or both, and test the upgrade path on a throwaway branch before you depend on it.
- How do I verify the bundle maps my columns to the correct Postgres types?
- Spike it in a disposable branch against a scratch PostgreSQL instance: install, register, define one entity with a jsonb column and one with an array column, then run doctrine:schema:validate and doctrine:migrations:diff. Inspect the generated DDL and confirm it emits jsonb rather than json or text, because a mapping mismatch here silently changes index support and operator behaviour. Only promote it once the DDL matches what you would have written by hand.
- What is the best alternative for mapping jsonb and array columns in Laravel or Eloquent?
- Use $table->jsonb() in migrations plus Eloquent casts such as array, AsArrayObject, or AsCollection, and write a small CastsAttributes class for anything more exotic like hstore, inet, or ranges. columnDefinition() in your migration covers the DDL side when Laravel's schema builder lacks a native method. You can read this bundle's type-conversion logic as a reference for the PHP-value side, but reimplement rather than copy given the LGPL-3.0 licence.