Laravel Database Copy Laravel Package

Getting Started

• Install the package with Composer and publish its config file. Inspect the published config first; it is the main place to define source/target connections and anonymization rules.
• Confirm the relevant Laravel database connections exist in config/database.php. In 1.0.1, set the anonymization connection explicitly rather than relying on the default connection.
• First use case: copy a production/staging database into a local or staging environment and anonymize PII before developers use it. Start with one table, e.g. users, anonymize email/name, run the package’s copy command, then query the target to verify no original values remain.
• Check the package README or php artisan list for the exact copy command signature and available options. 1.0.1 is an additive release focused on making the anonymization connection configurable; no breaking changes are apparent from the release note.

Implementation Patterns

• Environment refresh pipeline: treat production as a read-only source and staging/local as the target. Copy first, then run anonymizers through the configured anonymization connection. Keep connection credentials in .env, not in committed config.
• Per-table anonymizers: define rules close to the table/column they affect. Use closures or package-provided anonymizer classes for names, emails, phone numbers, addresses, and free-text fields. Preserve primary/foreign keys so relationships remain intact.
• Multiple connections: explicitly configure source, target, and anonymization connections. The new 1.0.1 behavior is useful when anonymization should run through a dedicated connection rather than whatever Laravel’s default connection happens to be. Make sure that connection points at the database containing the copied rows.
• Local bootstrap: wrap the package command in a Composer script, Makefile target, or custom Artisan command so developers can refresh local data consistently. Add an environment guard to prevent accidental production execution.
• Scheduled staging refresh: run the copy/anonymize flow from the scheduler or a queued job if appropriate. Back up the target first and log row counts or checksums before and after anonymization.
• Testing anonymizers: run against a small subset or a disposable test database first. Assert that sensitive columns no longer contain original values and that unique constraints, especially emails, are not violated by generated data.

Gotchas and Tips

• Config cache: after changing database-copy or anonymization connection settings, run php artisan config:clear or php artisan config:cache as appropriate. Stale config is a common source of “it anonymized the wrong database” bugs.
• Verify the anonymization connection: in 1.0.1, a missing or misconfigured anonymization connection can cause rules to run against the wrong database or fail because tables are absent. Log or assert DB::connection($name)->getDatabaseName() before running.
• Cross-database compatibility: copying between MySQL, PostgreSQL, and SQLite can fail on schema/type differences. Prefer matching engines for realistic refreshes, or test the target engine thoroughly.
• Large databases: copies and anonymization can be slow or memory-heavy. Run off-peak, monitor timeouts, and use chunking or package options if available.
• Foreign keys and constraints: anonymization must not break references. Disable/order constraints only when necessary, and re-enable them after the run.
• Destructive target: assume the target database will be overwritten. Back it up, require an explicit environment flag, and never let a local or staging command point at production.
• Anonymizer quality: make anonymizers deterministic where stable test data matters, idempotent where reruns are possible, and careful with unique columns. Cover JSON/text columns that may contain PII outside obvious name/email fields.
• Secrets and permissions: use least-privilege credentials for source and target. Do not commit production passwords, and avoid granting write access to production from developer machines.
• Extension point: prefer package-supported custom anonymizers or config hooks over post-processing raw SQL. That keeps the flow repeatable and easier to audit.