Adds methods to ActiveRecord::Migration to create and manage versioned database views in Rails applications.
Scenic is a Ruby gem that adds methods to ActiveRecord::Migration for creating and managing versioned database views in Rails applications. It solves the problem of integrating complex SQL views into Rails projects by providing a structured, versioned approach that works with Rails' schema format and migration system. This allows developers to use SQL views without switching to SQL schema dumps or duplicating SQL strings.
Rails developers who need to work with complex SQL queries, materialized views, or want to expose database views as ActiveRecord models. It's particularly useful for teams looking to optimize queries, aggregate data, or create read-only models backed by SQL views.
Developers choose Scenic because it seamlessly integrates database views into Rails conventions, offering versioning, reversible migrations, and generators that simplify view management. Its support for materialized views and multiple update strategies provides flexibility for performance-critical applications.
Versioned database views for Rails
Open-Awesome is built by the community, for the community. Submit a project, suggest an awesome list, or help improve the catalog on GitHub.
Maintains reversible migrations and versioned SQL definition files, preventing SQL string duplication and ensuring consistent schema history, as highlighted in the README's focus on migration consistency.
Supports concurrent refreshes and side-by-side update strategies to minimize locking, detailed in the README for performance-critical applications using cached query results.
Seamlessly fits into Rails workflows with generators like `scenic:view` and `scenic:model`, keeping views compatible with `schema.rb` without switching to SQL dumps.
Allows SQL views to back ActiveRecord models as first-class domain objects, enabling cleaner abstractions without special mixins, as demonstrated in the model generator examples.
Officially supports only PostgreSQL; other databases depend on third-party adapters that may be unstable or poorly maintained, a limitation openly admitted in the README's FAQ.
Views lack inherent primary keys, requiring manual configuration in models for ActiveRecord's `find`, `first`, and `last` methods to work—a common pain point noted in the README's troubleshooting section.
Refreshing materialized views can lock them for selects, and concurrent refreshes demand unique indexes, adding setup complexity and potential performance trade-offs, as warned in the documentation.