- How do I install this package in a Laravel project?
- Run `composer require flagception/database-activator` in your project directory. The package requires PHP 7.4+ and Laravel 8+ (or any PHP app using Doctrine DBAL 4.0+). No additional Laravel-specific setup is needed beyond Composer installation.
- Can I use this activator with Laravel’s database configuration?
- Yes. Pass Laravel’s DB config array directly to the `DatabaseActivator` constructor. For example, use `config('database.connections.mysql')` if your Laravel `.env` defines a MySQL connection. The package supports all DBAL-compatible connection formats.
- Does this work with Laravel’s Eloquent or Query Builder?
- No, this package is a standalone Flagception activator and doesn’t interact with Eloquent or Query Builder. It uses raw Doctrine DBAL for direct SQL operations, ensuring compatibility with any Laravel database setup without ORM dependencies.
- What Laravel versions does this package support?
- This package works with any Laravel version that supports PHP 7.4+ and Doctrine DBAL 4.0+. Since Laravel 8+ ships with DBAL 3.x by default, you may need to manually require `doctrine/dbal:^4.0` in `composer.json` if using older Laravel versions.
- How do I customize the database table or column names?
- Pass a second argument to `DatabaseActivator` as an associative array with keys `db_table`, `db_column_feature`, and `db_column_state`. For example, `new DatabaseActivator('dsn', ['db_table' => 'custom_flags', 'db_column_feature' => 'flag_name'])` will use your custom schema.
- Will this activator work in a Laravel microservices architecture?
- Yes, but consider adding a `service_namespace` column to the table to avoid conflicts. For example, prefix feature names with `service1_` or `service2_` in your activator logic. This prevents collisions when multiple services share the same database.
- How do I handle database connection failures in production?
- Implement retry logic using Laravel’s `retry` helper or a library like `spatie/laravel-retryable`. The activator itself doesn’t handle retries, but you can wrap the `FeatureManager` initialization in a retry block for resilience during transient DB outages.
- Can I add audit logs for flag changes (e.g., who updated a flag and when)?
- No, this activator only stores the `feature` and `state` columns by default. Extend the schema by adding `updated_at`, `updated_by`, or a separate audit table. Use Laravel’s `DB::statement()` or migrations to add these columns post-installation.
- Does this package support multi-environment flags (e.g., prod vs. staging)?
- Not natively, but you can implement this by adding an `environment` column to the table. Use a default value (e.g., `env('APP_ENV')`) when storing flags, then filter queries by environment in your activator logic or application code.
- What are the performance implications for large-scale Laravel apps?
- For high-traffic apps, index the `feature` column and consider caching frequent flags with Laravel’s cache system. The activator uses simple SELECT queries, but under heavy load, add a Redis layer (e.g., `flagception/redis-activator`) to offload reads while keeping DB writes minimal.