- How do I install cuonggt/dibi in a Laravel application?
- Install it with Composer, which registers the Dibi service provider through package auto-discovery. On Laravel 11+ skeletons, v0.7.0 also handles the explicit provider entry in bootstrap/providers.php, which previously caused facade-not-resolving failures. After installing, publish the configuration with php artisan dibi:publish and select the driver in config/database.php. No extra infrastructure or service dependency is required.
- Which Laravel and PHP versions does cuonggt/dibi support?
- v0.7.0 adds Laravel 13 support, widening the supported matrix alongside Laravel 11 and 12 on PHP 8.x. The changelog asserts the Laravel 13 support, but you should confirm whether the project's CI actually covers each version you run rather than assuming a passing 13 implies no regressions on 11 or 12. Teams still on Laravel 10 or earlier should note the provider-registration fix is a no-op for them and plan separately for the eventual skeleton upgrade. Always check the tested matrix for your exact PHP 8.2-8.5 target.
- How do I configure a Dibi connection in config/database.php?
- Publish the package config, then add a connection entry that uses the Dibi driver and points at your database credentials. Configuration is file-based and publishable, so it fits the normal Laravel workflow without any sidecar or external service. Because the package bridges Laravel's connection layer, Dibi's Fluent query builder can run alongside Eloquent and the native query builder. Keep the published config under version control so you can diff it before future publishes.
- What does php artisan dibi:publish write or overwrite?
- The command publishes the package configuration and the compiled front-end assets, which is why the Vite 8.x security bump in v0.7.0 only takes effect after you re-run it. Because publish overwrites, capture a diff of your currently published config first and re-apply any local edits afterwards. If you skip the republish, stale published assets persist and the advisory fix is not actually in place.
- Do Dibi queries appear in Laravel Telescope or DB::listen?
- Generally no. Dibi manages its own connections rather than routing through Laravel's PDO layer, so its traffic is typically invisible to DB::listen, Telescope's query tab, and PDO-based APM agents. This is an architectural consequence of the adapter design, not a bug, but it must be an explicitly accepted trade-off. If query-level observability is a hard requirement, plan for Dibi-side logging or stick to native PDO connections.
- Does the Dibi driver honour Laravel transactions, savepoints, and read/write splitting?
- You need to verify this rather than assume it. Because Dibi owns its connections, Laravel semantics such as nested transactions and savepoints, DB::transaction retries, and read/write connection splitting may not behave the same as with native drivers. Prove one read path and one transactional write path end-to-end against a real database before depending on them. Treat any mismatch as a design constraint to document, not something to patch around silently.
- Can I mix Dibi and Eloquent in the same request?
- Yes, structurally it works: the package registers a service provider, exposes a facade, and bridges the connection layer so Dibi queries can coexist with Eloquent and the query builder. The sharpest correctness hazard is mixing write paths across the two abstractions within a single request, especially around transactions. Decide early whether Dibi owns migrations and writes or only read/query paths, and enforce that boundary in code review.
- Is cuonggt/dibi stable enough for production use?
- It is a pre-1.0 package, so minor version bumps can carry behaviour changes without a major-version signal; pin an exact or tight constraint such as ^0.7 and read every changelog. There is also a bus-factor consideration: it is a single-maintainer package sitting on a single-maintainer upstream, so an internal fork or vendoring plan is worth deciding on up front. Combined with the observability gap, it is best treated as a deliberate, documented trade-off rather than a default choice.
- How do I upgrade cuonggt/dibi from 0.6 to 0.7?
- The release reads as additive plus fixes, with no removals or deprecations signalled, so it is low risk. The one mandatory operator action is re-running php artisan dibi:publish to land the rebuilt Vite assets that resolve the security advisories. Diff your existing published config before publishing and re-apply local changes, then tighten your Composer constraint to ^0.7 so the bump is deliberate rather than absorbed silently. Also re-check the pinned Dibi version against what the release expects.
- When is cuonggt/dibi worth using instead of Laravel's native query builder?
- It delivers the most value where your team already has Dibi fluency, such as legacy PHP applications, vendor codebases built on Dibi, or a migration off a Nette/Dibi stack. For greenfield work, Laravel's native query builder and Eloquent already cover the ground, and they keep you inside Telescope, DB::listen, and PDO-based APM tooling. Treat it as an adapter for interoperability rather than a replacement ORM.