Weave Code
Custom Index Bundle Laravel Package
intaro/custom-index-bundle
Symfony bundle for adding and managing custom Doctrine database indexes via configuration, so you can tune query performance without modifying entity mappings. Useful for optimizing large tables and controlling indexes from application config.
Annotation and command for control entity custom indexes
Frequently asked questions about Custom Index Bundle
- Does intaro/custom-index-bundle work with Laravel?
- No. It is a Symfony bundle built on Doctrine ORM metadata, not an Eloquent or Illuminate package, so there is no supported adapter path into a Laravel application. Porting the metadata reader and DDL generator into a custom Artisan command would be a reimplementation rather than adoption. For Laravel, put raw CREATE INDEX statements in a normal migration instead.
- How do I install and register the bundle in a Symfony project?
- Install it with Composer, then register the bundle in your Symfony bundle configuration so its metadata driver and schema listeners are active. After that you declare indexes as attributes or annotations on your Doctrine entities and let doctrine:schema:update or doctrine:migrations:diff produce the DDL. Treat the generated migration as a reviewable step rather than letting schema updates run automatically in production.
- Does it support Doctrine ORM 3?
- Yes. ORM 3 compatibility was added, which removes what was previously a hard pin to ORM 2 and the scheduling conflict that came with it. The new CI and PHPStan setup gives some confidence that the claimed support is actually exercised. DBAL coupling and the eventual ORM 4 or DBAL 5 bump remain future gates rather than current blockers.
- Which databases does this bundle actually support?
- PostgreSQL is the gating requirement, because the value comes from index shapes Doctrine's schema tool cannot express, such as GIN, GiST, partial, functional or expression, and covering indexes. MySQL and SQLite users get little or nothing from it. Confirm your target database before spending any time on a spike.
- What kinds of custom indexes can I declare on an entity?
- You describe the index name, columns, and flags in an attribute or annotation, and the bundle supports unique, partial, and compound definitions. On PostgreSQL it also covers expression and functional indexes plus covering indexes with included columns. Because the definition lives beside the entity, it stays versioned with the model.
- How does it keep indexes in sync with Doctrine schema tooling?
- The bundle attaches extra metadata to Doctrine entities, and the schema tooling emits matching DDL when you diff or update. Index-only changes therefore show up as generated migration steps instead of hand-edited SQL, and existing Doctrine-generated indexes are left untouched. The package supplements migrations rather than replacing them.
- Will creating an index lock my large table during deployment?
- It can. A non-concurrent index build takes a lock on the table, and CREATE INDEX CONCURRENTLY cannot run inside a transaction, which conflicts with how Doctrine migrations normally execute. For your largest tables, plan an out-of-band concurrent creation step in the deploy pipeline. Test the lock window against production-sized data before shipping.
- What happens if I remove the index metadata from an entity?
- You risk silent schema drift. If the metadata disappears the schema tooling may not reliably drop the physical index, so the database keeps an index nobody owns or documents. Verify with schema introspection after removals and add an explicit DROP INDEX migration where needed.
- Is the package safe to depend on in production?
- It has roughly 27 stars, no known dependents, and all recent changes come from a single maintainer, so downstream validation is thin. The addition of CI, PHPStan, and php-cs-fixer is a real improvement over unvalidated single-author code. Before adopting, name an internal owner willing to vendor or fork it if it goes stale.
- What are the alternatives to this bundle?
- Hand-written raw SQL migrations can express every index this package generates, in Doctrine or Laravel. You lose declarative entity-level metadata but gain zero dependency risk, and the executed SQL is identical. A time-boxed one to two engineer-day spell is reasonable only if you are on Symfony with Doctrine ORM 2 or 3 and PostgreSQL.
Weaver
How can I help you explore Laravel packages today?