Laravel Dm8 Laravel Package

Getting Started

This package extends Laravel's schema grammar with compileTables() and compileColumns() — the SQL compilers behind Laravel's schema introspection facade (Schema::getTables() / Schema::getColumns()). Start by confirming you're on a Laravel version that exposes those introspection methods (10.x+ / 11.x).

First steps:

1. Install via Composer and register the service provider per the package README.
2. Point a connection config at the driver this package targets.
3. Smoke-test the feature with a single call:

   Schema::connection('mydb')->getTables();
   Schema::connection('mydb')->getColumns('users');
   

4. Inspect the generated SQL via DB::connection('mydb')->listen(fn ($q) => dump($q->sql)) if the output looks wrong — the compiled SQL is what you'll debug most often.

First use case: using getTables()/getColumns() to drive a migration diff, a schema-dump command, or an admin UI that lists tables and column metadata without handcrafted queries.

Implementation Patterns

Schema introspection for tooling. The primary consumer of compileTables/compileColumns is anything that needs to reflect a schema: db:table-style commands, migration generators, diffing tools, or data-warehouse UIs. Wrap them in a small service rather than calling Schema:: directly throughout your app:

final class SchemaInspector
{
    public function tables(): array
    {
        return Schema::connection($this->name)->getTables();
    }

    public function columns(string $table): array
    {
        return Schema::connection($this->name)->getColumns($table);
    }
}

Multi-driver awareness. If the package wraps a non-default driver (ClickHouse, a columnar store, an external warehouse), keep the connection name configurable and inject it. Don't hardcode the default connection — compileColumns is driver-specific and calling it on the wrong connection will produce SQL the other engine rejects.

Migration/schema-dump integration. Hook the introspected schema into your own schema:dump equivalent by iterating getTables() and calling getColumns() per table. This is the most common real-world pattern: the compiler functions exist so tooling can build a schema representation without raw information_schema queries.

Assertions in tests. Assert on the shape of the returned arrays (keys like name, type, nullable, default) rather than exact driver strings, since type names differ across engines.

Gotchas and Tips

• Version coupling. Schema::getTables()/getColumns() arrive with Laravel 10.x's schema introspection API. On older Laravel versions the compilers exist but nothing calls them — you'll need to invoke the grammar's compileTables/compileColumns manually or upgrade.
• Grammar registration matters. These methods live on the schema grammar. If your connection's getSchemaGrammar() returns the default grammar instead of the package's, you'll get MethodDoesNotExist or, worse, base-grammar SQL. Verify the provider actually swaps the grammar for your driver.
• compileColumns needs a table name compiled safely — pass through Laravel's wrapTable() semantics. If you're calling the compiler directly (not via Schema::), make sure the table is wrapped to avoid reserved-word failures.
• Result keys vary by driver. getColumns() output isn't fully normalized across engines; don't assume every key (collation, comment, etc.) exists. Use array_key_exists or null-safe reads when building UIs.
• Cache the introspection in hot paths. Every getTables()/getColumns() call hits the database. In admin panels or loops, memoize per-request; these compilers are cheap to call but not free.
• Extension point: if you need extra metadata (engine, partitions, comment), the grammar is a good place to subclass and add compileTableOptions()-style methods rather than post-processing raw query results.
• Debugging tip: when introspection returns empty, log the compiled SQL first — usually the issue is the grammar not being applied or the wrong connection being resolved, not the SQL itself.