RecordLoader provides a simple and standardized way of populating databases from information described in a series of organized yaml files. It is intended to be used to generate a number of idempotent tasks, which can be run in both your production and development environments.
While written with ActiveRecord/Rails in mind, it is possible to use RecordLoader in different environments.
- Produce testable, reproducible data migrations across multiple environments
- Organize data into multiple files to provide context
- Add development environment specific data with .dev.yml files
- Keep work-in-progress isolated with .wip.yml files
- Rails generators to quickly create new record loaders
Add this line to your application's Gemfile:
gem 'record_loader'
And then execute:
bundle
Or install it yourself as:
gem install record_loader
If you are using Rails, you do not need to make any further changes, and all necessary hooks will be installed when generating your first record loader.
To execute all record loaders created for your project you can use the command:
rake record_loader:all
RecordLoader provides a generator to automatically build a loader, specs and the yaml files necessary to use it. You may need to manually modify the contents of those files to adapt to the data type you are defining. In addition, the first time you use it it will automatically install the necessary rake files and configuration. You can access this by running:
bundle exec rails g record_loader
Which will return the documentation:
{include:file:lib/generators/record_loader/USAGE}
Suppose you want to create a loader to maintain a selection of product types. You'll first use the generator:
$ bundle exec rails g record_loader product_type
exist
create config/record_loader/product_types/default_records.yml
create lib/record_loader/product_type_loader.rb
create lib/record_loader/tasks/record_loader/product_type.rake
create spec/data/record_loader/product_types/product_types_basic.yml
create spec/lib/record_loader/product_type_loader_spec.rb
skip lib/record_loader/application_record_loader.rb
identical lib/tasks/record_loader.rake
This will create several files:
Adds the record_loader:all rake task which can be used to trigger all record loaders.
Application specific base class for customization.
Example yaml file to begin populating with your record information. Record Loaders will load all yaml files from within
this directory, so it is possible to separate your records into multiple different files for better organization.
In addition yaml files ending in .dev.yml
and .wip.yml
exhibit special behaviour.
See dev and wip files.
The actual loader. It will look something like this:
# frozen_string_literal: true
# This file was automatically generated via `rails g record_loader`
# RecordLoader handles automatic population and updating of database records
# across different environments
# @see https://rubydoc.info/github/sanger/record_loader/
module RecordLoader
# Creates the specified plate types if they are not present
class ProductTypeLoader < ApplicationRecordLoader
config_folder 'product_types'
def create_or_update!(name, options)
ProductType.create_with(options).find_or_create_by!(name: name)
end
end
end
The config_folder
specifies which directory under config/record_loader
will be used to source the yaml files.
The method create_or_update!
will create the actual records, and should be idempotent (ie. calling it multiple times will
have the same effect as calling it once). create_or_update!
will be called once for each entry in the yaml files,
with the first argument being the key, and the second argument being the value, usually a hash of options.
This contains the record_loader:product_type
which will trigger the record loader, and also ensures that
record_loader:product_type
will get invoked on calling record_loader:all
.
A basic configuration for testing the loader. Tests use a separate directory to avoid coupling your specs to the data.
A basic rspec spec file for testing your loader. By default this just confirms that your loader creates the expected number of records, and that it is idempotent.
Each loader can have one or more yaml files contained within its config directory. Most files will be aggregated together and only serve to provide a means of organization. However it is possible to add extra behaviour:
.dev.yml
files will only be loaded in development environments. This is useful for seeding data for quick testing, but
which will not be needed in production environments. This may include test user accounts, dummy projects or quick
start data.
.wip.yml
files will only be loaded if explicitly enabled via a WIP environmental variable. For example the file
my_feature.wip.yml
will run if the WIP env is set to my_feature
. Multiple WIP flags can be set at the same time by
providing a comma separated list. eg. WIP=my_feature,other_feature
If you have an existing feature flag system you can use this instead by adding a wip_list
method to
RecordLoader::ApplicationRecordLoader
which returns an array of enabled feature names. For example:
def wip_list
FeatureFlags.active.pluck(:name)
end
Sometimes one loader will be dependent on the output of another. If this is the case, you can simply configure its rake task to use the other as a pre-requisite. Rake's dependency handling is smart enough to ensure each task only gets run once.
For example
namespace :record_loader do
desc 'Automatically generate Dependent through DependentLoader'
task dependent: [:environment, 'record_loader:prerequisite'] do
RecordLoader::DependentLoader.new.create!
end
end
It can be useful to set rake record_loader:all
to run automatically on deployment.
It is recommend you trigger this after migrations have run.
This section is relevant to developers within the Sanger only. Other users of the Gem should hook into their own deployment systems as they see fit.
In Production Software Development at the Sanger we have the Ansible deployment project configured to run
rake application:post_deploy
after migrations for selected applications. If you wish to take advantage of this
uncomment the appropriate line in lib/tasks/record_loader.rake
. You should also ensure that your application has
the post_deploy tasks enabled by setting the post_deploy to true for your application.
Currently this behaviour is configured as part of the 'rails' role, and will need to be set-up independently for any non-Rails ruby applications.
In non-rails environments you can use the {RecordLoader::Adapter::Basic} adapter to avoid Rails specific functionality. This is the default adapter for {RecordLoader::Base}, although it is still recommended that you create an application specific class that inherits from this to allow for customization. Your custom record loaders can then inherit from this class instead.
See {RecordLoader::Adapter} for information about custom adapters.
After checking out the repo, run bin/setup
to install dependencies. Then, run rake spec
to run the tests. You can
also run bin/console
for an interactive prompt that will allow you to experiment.
To install this gem onto your local machine, run bundle exec rake install
. To release a new version, update the
version number in version.rb
, ensure the CHANGELOG.md is updated and that everything is committed.
Then run bundle exec rake release
, which will create a git tag for the version, push git commits and tags, and push
the .gem
file to rubygems.org.
Bug reports and pull requests are welcome on GitHub at https://github.com/sanger/record_loader.
The gem is available as open source under the terms of the MIT License.