Laravel Tail Db Laravel Package

Getting Started

The package is designed to work against your application's configured database connection rather than a hard-coded one. Start by installing it and publishing its config:

composer require <vendor>/<package>
php artisan vendor:publish --provider="<Vendor>\<Package>\<PackageServiceProvider>"

The service provider is auto-discovered, so no manual registration is needed in a standard Laravel 9+/10+/11+ app. Look at config/<package>.php first — that is where the connection name, table/prefix settings, and any driver-specific behaviour live. Most day-to-day friction comes from this file, not from the package code.

First use case: point the package at your default connection and confirm it resolves correctly:

php artisan <package>:check   # or whichever diagnostic command ships with the release

Then exercise it from a tinker session against a non-default connection to confirm it follows config('database.default') and per-connection overrides rather than caching the first name it sees.

The 1.1.3 release is relevant here: previously, an application that set the database name dynamically at runtime (per-tenant connections, config(['database.connections.tenant.database' => $name]), or a DB_DATABASE resolved in a service provider) could hit an error because the package captured the name too early. If your app switches databases at runtime, 1.1.3 is the minimum version you should pin.

Implementation Patterns

Configuration-first, then bindings. Prefer declaring connections in config/database.php and letting the package read them, rather than passing database names as method arguments. This keeps the dynamic-name path (the one fixed in 1.1.3) as the single code path in your app.

Resolve inside the request/job, not at boot. If your database name is dynamic, do the config([...]) mutation in middleware or at the top of the job's handle(), then resolve the package's service from the container afterwards. Anything resolved in a service provider's register() runs before your mutation and will see the stale name.

Per-tenant / per-connection wrapper. A thin application-level service keeps call sites clean:

class TenantDatabase
{
    public function run(Tenant $tenant, Closure $callback)
    {
        $previous = config('database.connections.tenant.database');
        config(['database.connections.tenant.database' => $tenant->database]);
        DB::purge('tenant');

        try {
            return $callback(app(PackageContract::class));
        } finally {
            config(['database.connections.tenant.database' => $previous]);
            DB::purge('tenant');
        }
    }
}

Note the DB::purge() calls — without them Laravel hands back a cached connection pointing at the old database, which is the most common "the package ignored my dynamic name" report.

Queue and job integration. Pass the tenant/database identifier as a job property, not as a resolved connection. Re-establish the connection in handle() so retries and delayed jobs run against the right database.

Testing. Use RefreshDatabase on a static test connection, and cover the dynamic path with a dedicated test that mutates config() at runtime — that is exactly the scenario 1.1.3 addresses, and it is worth a regression test in your own suite.

Events and logging. If the package dispatches events around its operations, hook them for audit logging rather than wrapping every call site.

Gotchas and Tips

• config:cache and dynamic names. A cached config freezes whatever DB_DATABASE resolved at build time. If your database name is computed at runtime, exclude that key from caching or set it after boot; otherwise 1.1.3's fix cannot help you.
• Stale connections in long-running processes. Under Octane, Horizon, or queue workers, the connection persists between jobs. Always DB::purge($connection) after changing the database name.
• Order of resolution matters. The package reads the connection when it is resolved from the container. If you mutate config after resolving, you get the old name. Resolve late, or forget/re-resolve the instance.
• Verify the version. composer show <vendor>/<package> should report 1.1.3 or later if you rely on runtime database-name changes. On 1.1.2 and below, expect errors when the name is not present in static config.
• Debugging the dynamic path. Dump config('database.connections.<name>.database') and DB::connection($name)->getDatabaseName() side by side — a mismatch tells you immediately whether the problem is config timing or connection caching.
• Special characters in database names. Names containing dots or hyphens may need quoting depending on the driver; test with a realistic tenant name rather than testing.
• SQLite and in-memory databases. :memory: does not behave like a dynamically-set name; keep test configuration explicit so you do not mask the bug the release fixed.
• Extension points. Prefer the package's published config and container bindings over subclassing internals; the 1.1.3 patch touched name resolution, which is precisely the area most likely to change again.
• Upgrade cost. This is a patch release with no API surface changes — safe to take on a minor-version bump, but re-run your tenant-switching tests since the fix alters when the name is read.