noid-rails 3.0.0

checksums.yaml

@@ -0,0 +1,7 @@
+---
+SHA256:
+  metadata.gz: 85e1bde3f1de25e99f93d8d274bab86c7aa9a62abaaf6d4a8b42b31784c5f101
+  data.tar.gz: b18842c43ca3fe1db2b645bc3b763642df52d0c7d81ba3a8624c0862222c6a3f
+SHA512:
+  metadata.gz: 4f8404a7e825b8f290cec17553b48d71dba21b443772c284f900e9d7665d7fd36697b4296b8e7b8d091f6208040a5c17a655428ef72e6b0836b619f4c2397d5c
+  data.tar.gz: 9c2229a1871082d14ddc8265a954f649011e2f9594e9ce64d159da1f374cd655cbdbea233b4424f3b49df2d83061a64c477846a84a0d18c8b3e89ecef5f38c8c

data/.gitignore

@@ -0,0 +1,36 @@
+*.rbc
+capybara-*.html
+/log
+/tmp
+/db/*.sqlite3
+/public/system
+/coverage/
+/spec/tmp
+**.orig
+rerun.txt
+pickle-email-*.html
+.byebug_history
+
+# TODO Comment out these rules if you are OK with secrets being uploaded to the repo
+config/initializers/secret_token.rb
+config/secrets.yml
+
+## Environment normalisation:
+/.bundle
+/vendor/bundle
+
+# these should all be checked in to normalise the environment:
+Gemfile.lock
+.ruby-gemset
+.ruby-version
+pkg
+
+# unless supporting rvm < 1.11.0 or doing something fancy, ignore this:
+.rvmrc
+
+# if using bower-rails ignore default bower_components path bower.json files
+/vendor/assets/bower_components
+*.bowerrc
+bower.json
+
+.internal_test_app

data/.rspec

@@ -0,0 +1,2 @@
+--color
+--require spec_helper

data/.rubocop.yml

@@ -0,0 +1,24 @@
+require: rubocop-rspec
+inherit_from: .rubocop_todo.yml
+
+AllCops:
+  TargetRubyVersion: 2.3
+  DisplayCopNames: true
+
+Bundler/DuplicatedGem:
+  Enabled: false
+
+Rails:
+  Enabled: true
+
+RSpec/NestedGroups:
+  Max: 4
+
+Metrics/BlockLength:
+  Exclude:
+    - 'spec/**/*'
+    - 'lib/tasks/**/*.rake'
+
+Naming/FileName:
+  Exclude:
+    - 'lib/noid-rails.rb'

data/.rubocop_todo.yml

@@ -0,0 +1,107 @@
+require: rubocop-rspec
+
+# This configuration was generated by
+# `rubocop --auto-gen-config`
+# on 2016-10-25 09:12:51 -0700 using RuboCop version 0.42.0.
+# The point is for the user to remove these configuration records
+# one by one as the offenses are removed from the code base.
+# Note that changes in the inspected code, or installation of new
+# versions of RuboCop, may require this file to be generated again.
+
+# Offense count: 47
+# Configuration parameters: AllowHeredoc, AllowURI, URISchemes.
+# URISchemes: http, https
+Metrics/LineLength:
+  Max: 120
+
+# Offense count: 2
+# Configuration parameters: Max.
+RSpec/ExampleLength:
+  Exclude:
+    - 'spec/unit/db_minter_spec.rb'
+    - 'spec/unit/file_minter_spec.rb'
+
+RSpec/MessageSpies:
+  Enabled: false
+
+RSpec/ExpectInHook:
+  Exclude:
+    - 'spec/support/shared_examples/minter.rb'
+
+# Offense count: 6
+# Configuration parameters: CustomTransform.
+RSpec/FilePath:
+  Exclude:
+    - 'spec/unit/config_spec.rb'
+    - 'spec/unit/db_minter_spec.rb'
+    - 'spec/unit/file_minter_spec.rb'
+    - 'spec/unit/noid_spec.rb'
+    - 'spec/unit/service_spec.rb'
+    - 'spec/unit/rspec_spec.rb'
+
+# Offense count: 9
+RSpec/LeadingSubject:
+  Exclude:
+    - 'spec/unit/config_spec.rb'
+    - 'spec/unit/file_minter_spec.rb'
+
+# Offense count: 3
+RSpec/InstanceVariable:
+  Exclude:
+    - 'spec/unit/rspec_spec.rb'
+
+# Offense count: 4
+RSpec/MessageChain:
+  Exclude:
+    - 'spec/unit/config_spec.rb'
+
+# Offense count: 5
+# Configuration parameters: EnforcedStyle, SupportedStyles.
+# SupportedStyles: allow, expect
+RSpec/MessageExpectation:
+  Exclude:
+    - 'spec/support/shared_examples/minter.rb'
+    - 'spec/unit/service_spec.rb'
+
+# Offense count: 7
+RSpec/MultipleExpectations:
+  Max: 5
+
+# Offense count: 36
+RSpec/NamedSubject:
+  Exclude:
+    - 'spec/support/shared_examples/minter.rb'
+    - 'spec/unit/config_spec.rb'
+    - 'spec/unit/db_minter_spec.rb'
+    - 'spec/unit/file_minter_spec.rb'
+    - 'spec/unit/noid_spec.rb'
+    - 'spec/unit/service_spec.rb'
+
+# Offense count: 12
+# Configuration parameters: MaxNesting.
+RSpec/NestedGroups:
+  Exclude:
+    - 'spec/unit/config_spec.rb'
+    - 'spec/unit/noid_spec.rb'
+    - 'spec/unit/rspec_spec.rb'
+
+# Offense count: 3
+# Configuration parameters: IgnoreSymbolicNames.
+RSpec/VerifiedDoubles:
+  Exclude:
+    - 'spec/unit/config_spec.rb'
+    - 'spec/unit/service_spec.rb'
+
+# Offense count: 11
+Style/Documentation:
+  Exclude:
+    - 'spec/**/*'
+    - 'test/**/*'
+    - 'app/models/minter_state.rb'
+    - 'db/migrate/20160610010003_create_minter_states.rb'
+    - 'db/migrate/20161021203429_rename_minter_state_random_to_rand.rb'
+
+
+Lint/AmbiguousBlockAssociation:
+  Exclude:
+    - 'spec/unit/rspec_spec.rb'

data/.travis.yml

@@ -0,0 +1,11 @@
+language: ruby
+cache: bundler
+sudo: false
+rvm:
+  - 2.4.1
+env:
+  global:
+    - NOKOGIRI_USE_SYSTEM_LIBRARIES=true
+  matrix:
+    - "RAILS_VERSION=5.0.3"
+    - "RAILS_VERSION=5.1.1"

data/CONTRIBUTING.md

@@ -0,0 +1,159 @@
+# How to Contribute
+
+We want your help to make Project Hydra great.
+There are a few guidelines that we need contributors to follow so that we can have a chance of keeping on top of things.
+
+## Code of Conduct
+
+The Hydra community is dedicated to providing a welcoming and positive experience for all its
+members, whether they are at a formal gathering, in a social setting, or taking part in activities
+online.  Please see our [Code of Conduct](https://wiki.duraspace.org/display/hydra/Code+of+Conduct)
+for more information.
+
+## Hydra Project Intellectual Property Licensing and Ownership
+
+All code contributors must have an Individual Contributor License Agreement (iCLA) on file with the Hydra Project Steering Group.
+If the contributor works for an institution, the institution must have a Corporate Contributor License Agreement (cCLA) on file.
+
+https://wiki.duraspace.org/display/hydra/Hydra+Project+Intellectual+Property+Licensing+and+Ownership
+
+You should also add yourself to the `CONTRIBUTORS.md` file in the root of the project.
+
+## Contribution Tasks
+
+* Reporting Issues
+* Making Changes
+* Documenting Code
+* Committing Changes
+* Submitting Changes
+* Reviewing and Merging Changes
+
+### Reporting Issues
+
+* Make sure you have a [GitHub account](https://github.com/signup/free)
+* Submit a [Github issue](./issues) by:
+  * Clearly describing the issue
+    * Provide a descriptive summary
+    * Explain the expected behavior
+    * Explain the actual behavior
+    * Provide steps to reproduce the actual behavior
+
+### Making Changes
+
+* Fork the repository on GitHub
+* Create a topic branch from where you want to base your work.
+  * This is usually the master branch.
+  * To quickly create a topic branch based on master; `git branch fix/master/my_contribution master`
+  * Then checkout the new branch with `git checkout fix/master/my_contribution`.
+  * Please avoid working directly on the `master` branch.
+  * You may find the [hub suite of commands](https://github.com/defunkt/hub) helpful
+* Make sure you have added sufficient tests and documentation for your changes.
+  * Test functionality with RSpec; est features / UI with Capybara.
+* Run _all_ the tests to assure nothing else was accidentally broken.
+
+### Documenting Code
+
+* All new public methods, modules, and classes should include inline documentation in [YARD](http://yardoc.org/).
+  * Documentation should seek to answer the question "why does this code exist?"
+* Document private / protected methods as desired.
+* If you are working in a file with no prior documentation, do try to document as you gain understanding of the code.
+  * If you don't know exactly what a bit of code does, it is extra likely that it needs to be documented. Take a stab at it and ask for feedback in your pull request. You can use the 'blame' button on GitHub to identify the original developer of the code and @mention them in your comment.
+  * This work greatly increases the usability of the code base and supports the on-ramping of new committers.
+  * We will all be understanding of one another's time constraints in this area.
+* YARD examples:
+  * [Hydra::Works::RemoveGenericFile](https://github.com/projecthydra-labs/hydra-works/blob/master/lib/hydra/works/services/generic_work/remove_generic_file.rb)
+  * [ActiveTriples::LocalName::Minter](https://github.com/ActiveTriples/active_triples-local_name/blob/master/lib/active_triples/local_name/minter.rb)
+* [Getting started with YARD](http://www.rubydoc.info/gems/yard/file/docs/GettingStarted.md)
+
+### Committing changes
+
+* Make commits of logical units.
+  * Your commit should include a high level description of your work in HISTORY.textile
+* Check for unnecessary whitespace with `git diff --check` before committing.
+* Make sure your commit messages are [well formed](http://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html).
+* If you created an issue, you can close it by including "Closes #issue" in your commit message. See [Github's blog post for more details](https://github.com/blog/1386-closing-issues-via-commit-messages)
+
+```
+    Present tense short summary (50 characters or less)
+
+    More detailed description, if necessary. It should be wrapped to 72
+    characters. Try to be as descriptive as you can, even if you think that
+    the commit content is obvious, it may not be obvious to others. You
+    should add such description also if it's already present in bug tracker,
+    it should not be necessary to visit a webpage to check the history.
+
+    Include Closes #<issue-number> when relavent.
+
+    Description can have multiple paragraphs and you can use code examples
+    inside, just indent it with 4 spaces:
+
+        class PostsController
+          def index
+            respond_to do |wants|
+              wants.html { render 'index' }
+            end
+          end
+        end
+
+    You can also add bullet points:
+
+    - you can use dashes or asterisks
+
+    - also, try to indent next line of a point for readability, if it's too
+      long to fit in 72 characters
+```
+
+### Submitting Changes
+
+* Read the article ["Using Pull Requests"](https://help.github.com/articles/using-pull-requests) on GitHub.
+* Make sure your branch is up to date with its parent branch (i.e. master)
+  * `git checkout master`
+  * `git pull --rebase`
+  * `git checkout <your-branch>`
+  * `git rebase master`
+  * It is a good idea to run your tests again.
+* If you've made more than one commit take a moment to consider whether squashing commits together would help improve their logical grouping.
+  * [Detailed Walkthrough of One Pull Request per Commit](http://ndlib.github.io/practices/one-commit-per-pull-request/)
+  * `git rebase --interactive master` ([See Github help](https://help.github.com/articles/interactive-rebase))
+  * Squashing your branch's changes into one commit is "good form" and helps the person merging your request to see everything that is going on.
+* Push your changes to a topic branch in your fork of the repository.
+* Submit a pull request from your fork to the project.
+
+### Reviewing and Merging Changes
+
+We adopted [Github's Pull Request Review](https://help.github.com/articles/about-pull-request-reviews/) for our repositories.
+Common checks that may occur in our repositories:
+
+1. Travis CI - where our automated tests are running
+2. Hound CI - where we check for style violations
+3. Approval Required - Github enforces at least one person approve a pull request. Also, all reviewers that have chimed in must approve.
+4. CodeClimate - is our code remaining healthy (at least according to static code analysis)
+
+If one or more of the required checks failed (or are incomplete), the code should not be merged (and the UI will not allow it). If all of the checks have passed, then anyone on the project (including the pull request submitter) may merge the code.
+
+*Example: Carolyn submits a pull request, Justin reviews the pull request and approves. However, Justin is still waiting on other checks (Travis CI is usually the culprit), so he does not merge the pull request. Eventually, all of the checks pass. At this point, Carolyn or anyone else may merge the pull request.*
+
+#### Things to Consider When Reviewing
+
+First, the person contributing the code is putting themselves out there. Be mindful of what you say in a review.
+
+* Ask clarifying questions
+* State your understanding and expectations
+* Provide example code or alternate solutions, and explain why
+
+This is your chance for a mentoring moment of another developer. Take time to give an honest and thorough review of what has changed. Things to consider:
+
+  * Does the commit message explain what is going on?
+  * Does the code changes have tests? _Not all changes need new tests, some changes are refactors_
+  * Do new or changed methods, modules, and classes have documentation?
+  * Does the commit contain more than it should? Are two separate concerns being addressed in one commit?
+  * Does the description of the new/changed specs match your understanding of what the spec is doing?
+
+If you are uncertain, bring other contributors into the conversation by assigning them as a reviewer.
+
+# Additional Resources
+
+* [General GitHub documentation](http://help.github.com/)
+* [GitHub pull request documentation](http://help.github.com/send-pull-requests/)
+* [Pro Git](http://git-scm.com/book) is both a free and excellent book about Git.
+* [A Git Config for Contributing](http://ndlib.github.io/practices/my-typical-per-project-git-config/)

data/Gemfile

@@ -0,0 +1,39 @@
+# frozen_string_literal: true
+
+source 'https://rubygems.org'
+
+# Specify your gem's dependencies in noid-rails.gemspec
+gemspec
+
+group :development, :test do
+  gem 'byebug' unless ENV['CI']
+  gem 'coveralls', require: false
+end
+
+# BEGIN ENGINE_CART BLOCK
+# engine_cart: 1.0.1
+# engine_cart stanza: 0.10.0
+# the below comes from engine_cart, a gem used to test this Rails engine gem in the context of a Rails app.
+file = File.expand_path('Gemfile', ENV['ENGINE_CART_DESTINATION'] ||
+                                   ENV['RAILS_ROOT'] ||
+                                   File.expand_path('.internal_test_app', File.dirname(__FILE__)))
+if File.exist?(file)
+  begin
+    eval_gemfile file
+  rescue Bundler::GemfileError => e
+    Bundler.ui.warn '[EngineCart] Skipping Rails application dependencies:'
+    Bundler.ui.warn e.message
+  end
+else
+  Bundler.ui.warn "[EngineCart] Unable to find test application dependencies in #{file}, using placeholder dependencies"
+
+  if ENV['RAILS_VERSION']
+    if ENV['RAILS_VERSION'] == 'edge'
+      gem 'rails', github: 'rails/rails'
+      ENV['ENGINE_CART_RAILS_OPTIONS'] = '--edge --skip-turbolinks'
+    else
+      gem 'rails', ENV['RAILS_VERSION']
+    end
+  end
+end
+# END ENGINE_CART BLOCK

data/LICENSE

@@ -0,0 +1,15 @@
+##########################################################################
+# Copyright 2015 Penn State University
+# Additional copyright may be held by others, as reflected in the commit log
+#
+# Licensed under the Apache License, Version 2.0 (the "License");
+# you may not use this file except in compliance with the License.
+# You may obtain a copy of the License at
+#
+#     http://www.apache.org/licenses/LICENSE-2.0
+#
+# Unless required by applicable law or agreed to in writing, software
+# distributed under the License is distributed on an "AS IS" BASIS,
+# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+# See the License for the specific language governing permissions and
+# limitations under the License.

data/README.md

@@ -0,0 +1,214 @@
+Code: [![Version](https://badge.fury.io/rb/noid-rails.png)](http://badge.fury.io/rb/noid-rails)
+[![Build Status](https://travis-ci.org/projecthydra/noid-rails.png?branch=master)](https://travis-ci.org/projecthydra/noid-rails)
+[![Coverage Status](https://coveralls.io/repos/github/projecthydra/noid-rails/badge.svg?branch=master)](https://coveralls.io/github/projecthydra/noid-rails?branch=master)
+[![Code Climate](https://codeclimate.com/github/projecthydra/noid-rails/badges/gpa.svg)](https://codeclimate.com/github/projecthydra/noid-rails)
+[![Dependency Status](https://gemnasium.com/projecthydra/noid-rails.png)](https://gemnasium.com/projecthydra/noid-rails)
+
+Docs: [![Documentation Status](https://inch-ci.org/github/projecthydra/noid-rails.svg?branch=master)](https://inch-ci.org/github/projecthydra/noid-rails)
+[![API Docs](http://img.shields.io/badge/API-docs-blue.svg)](http://rubydoc.info/gems/noid-rails)
+[![Contribution Guidelines](http://img.shields.io/badge/CONTRIBUTING-Guidelines-blue.svg)](./CONTRIBUTING.md)
+[![Apache 2.0 License](http://img.shields.io/badge/APACHE2-license-blue.svg)](./LICENSE)
+
+# Noid::Rails
+
+Override your ActiveFedora-based applications with opaque [Noid](https://wiki.ucop.edu/display/Curation/NOID)-based identifiers.
+
+**This gem depends only upon ActiveFedora, not on Hydra or HydraHead**
+
+# Table of Contents
+
+  * [Installation](#installation)
+  * [Usage](#usage)
+    * [Minting and validating identifiers](#minting-and-validating-identifiers)
+    * [ActiveFedora integration](#activefedora-integration)
+      * [Identifier/URI translation](#identifieruri-translation)
+    * [Overriding default behavior](#overriding-default-behavior)
+      * [Use database-based minter state](#use-database-based-minter-state)
+      * [Identifier template](#identifier-template)
+      * [Custom minters](#custom-minters)
+  * [Help](#help)
+  * [Acknowledgments](#acknowledgments)
+
+# Installation
+
+Add this line to your application's Gemfile:
+
+    gem 'noid-rails'
+
+And then execute:
+
+    $ bundle install
+
+Or install it yourself via:
+
+    $ gem install noid-rails
+
+# Usage
+
+## Minting and validating identifiers
+
+Mint a new Noid:
+
+```ruby
+noid_service = Noid::Rails::Service.new
+noid = noid_service.mint
+```
+
+This creates a Noid with the default identifier template, which you can override (see below).  Now that you have a service object with a template, you can also use it to validate identifiers to see if they conform to the template:
+
+```ruby
+noid_service.valid? 'xyz123foobar'
+> false
+```
+
+## ActiveFedora integration
+
+To get ActiveFedora to automatically call your Noid service whenever a new ActiveFedora object is saved, include the `Noid::Rails::Model`, e.g.:
+
+```ruby
+# app/models/my_object.rb
+require 'noid-rails'
+
+class MyObject < ActiveFedora::Base
+  ## This overrides the default behavior, which is to ask Fedora for an id
+  # @see ActiveFedora::Persistence.assign_id
+  def assign_id
+    service.mint
+  end
+
+  private
+
+  def service
+    @service ||= Noid::Rails::Service.new
+  end
+end
+```
+
+### Identifier/URI translation
+
+As Noid::Rails overrides the default identifier minting strategy in ActiveFedora, you will need to let ActiveFedora know how to translate identifiers into URIs and vice versa so that identifiers are laid out in a sustainable way in Fedora.  Add the following to e.g. `config/initializers/active_fedora.rb`:
+
+```ruby
+baseparts = 2 + [(Noid::Rails::Config.template.gsub(/\.[rsz]/, '').length.to_f / 2).ceil, 4].min
+ActiveFedora::Base.translate_uri_to_id = lambda do |uri|
+                                           uri.to_s.sub(baseurl, '').split('/', baseparts).last
+                                         end
+ActiveFedora::Base.translate_id_to_uri = lambda do |id|
+                                           "#{baseurl}/#{Noid::Rails.treeify(id)}"
+                                         end
+```
+
+This will make sure your objects have Noid-like identifiers (e.g. `bb22bb22b`) that map to URIs in Fedora (e.g. `bb/22/bb/22/bb22bb22b`).
+
+## Overriding default behavior
+
+The default minter in Noid::Rails is the file-backed minter to preserve default behavior.
+
+To better support multi-host production installations that expect a shared database but not necessarily a shared filesystem (e.g., between load-balanced Rails applications), we highly recommend swapping in the database-backed minter.
+
+### Use database-based minter state
+
+The database-based minter stores minter state information in your application's relational database. To use it, you'll first need to run the install generator:
+
+```bash
+$ rails generate active_fedora:noid:install
+```
+
+This will create the necessary database migrations.
+
+Then run `rake db:migrate`
+
+To start minting identifiers with the new minter, override the AF::Noid configuration in e.g. `config/initializers/noid-rails.rb`:
+
+```ruby
+require 'active_fedora/noid'
+
+Noid::Rails.configure do |config|
+  config.minter_class = Noid::Rails::Minter::Db
+end
+```
+
+Using the database-backed minter can cause problems with your test suite, where it is often sensible to wipe out database rows between tests (which destroys the database-backed minter's state, which renders it unusable). To deal with this and still get the benefits of using the database-backed minter in development and production environments, you'll also want to add the following helper to your `spec/spec_helper.rb`:
+
+```ruby
+require 'active_fedora/noid/rspec'
+
+RSpec.configure do |config|
+  include Noid::Rails::RSpec
+
+  config.before(:suite) { disable_production_minter! }
+  config.after(:suite)  { enable_production_minter! }
+end
+```
+
+If you switch to the new database-backed minter and want to include in that minter the state of your current file-backed minter, Noid::Rails 2.x provides a new rake task that will copy your minter's state from the filesystem to the database:
+
+```bash
+# For migrating minter state from a file to a database
+$ rake noid:rails:migrate:file_to_database
+# For migrating minter state from a database to a file
+$ rake noid:rails:migrate:database_to_file
+```
+
+### Identifier template
+
+To override the default identifier pattern -- a nine-character string consisting of two alphanumeric digits, two numeric digits, two alphanumeric digits, two numeric digits, and a check digit -- put the following code in e.g. `config/initializers/noid-rails.rb`:
+
+```ruby
+require 'noid-rails'
+
+Noid::Rails.configure do |config|
+  config.template = '.ddddd'
+end
+```
+
+For more information about the format of Noid patterns, see pages 8-10 of the [Noid documentation](https://wiki.ucop.edu/download/attachments/16744482/noid.pdf).
+
+### Custom minters
+
+If you don't want your minter's state to be persisted, you may also write and configure your own minter.  First write up a minter class that looks like the following:
+
+```ruby
+class MyMinter < Noid::Rails::Minter::Base
+  def valid?(identifier)
+    # return true/false if you care about ids conforming to templates
+  end
+
+  def read
+    # return current minter state
+  end
+
+  def write!(state)
+    # write a passed-in minter state
+  end
+
+  protected
+
+  def next_id
+    # return the next identifier from the minter
+  end
+end
+```
+
+Then add your new minter class to the Noid::Rails configuration (`config/initializers/noid-rails.rb`):
+
+```ruby
+require 'noid-rails'
+
+Noid::Rails.configure do |config|
+  config.minter_class = MyMinter
+end
+```
+
+And the service will delegate minting and validating to an instance of your customized minter class.
+
+# Help
+
+If you have questions or need help, please email [the Hydra community tech list](mailto:hydra-tech@googlegroups.com) or stop by the #dev channel in [the Hydra community Slack team](https://wiki.duraspace.org/pages/viewpage.action?pageId=43910187#Getintouch!-Slack): [![Slack Status](http://slack.projecthydra.org/badge.svg)](http://slack.projecthydra.org/)
+
+# Acknowledgments
+
+This software has been developed by and is brought to you by the Hydra community.  Learn more at the
+[Project Hydra website](http://projecthydra.org/).
+
+![Project Hydra Logo](http://sufia.io/assets/images/hydra_logo.png)

data/Rakefile

@@ -0,0 +1,23 @@
+# frozen_string_literal: true
+
+require 'bundler/gem_tasks'
+require 'rspec/core/rake_task'
+require 'engine_cart/rake_task'
+require 'rubocop/rake_task'
+
+Dir.glob('lib/tasks/*.rake').each { |r| import r }
+
+desc 'Run test suite'
+task :spec do
+  RSpec::Core::RakeTask.new
+end
+
+desc 'Run style checker'
+RuboCop::RakeTask.new(:rubocop) do |task|
+  task.fail_on_error = true
+end
+
+desc 'Continuous Integration (generate test app and run tests)'
+task ci: ['rubocop', 'engine_cart:generate', 'spec']
+
+task default: :ci

data/app/models/minter_state.rb

@@ -0,0 +1,16 @@
+# frozen_string_literal: true
+
+class MinterState < ApplicationRecord
+  validates :namespace, presence: true, uniqueness: true
+  validates :template, presence: true
+  validates :template, format: { with: Object.const_get('Noid::Template::VALID_PATTERN'), message: 'value fails regex' }
+
+  # Creates an initial row for the namespace.
+  # @return [MinterState] the initial minter state
+  def self.seed!(namespace:, template:)
+    create!(
+      namespace: namespace,
+      template: template
+    )
+  end
+end

data/db/migrate/20160610010003_create_minter_states.rb

@@ -0,0 +1,16 @@
+# frozen_string_literal: true
+
+class CreateMinterStates < ActiveRecord::Migration[4.2]
+  def change
+    create_table :minter_states do |t|
+      t.string :namespace, null: false, default: 'default'
+      t.string :template, null: false
+      t.text :counters
+      t.bigint :seq, default: 0
+      t.binary :random
+      t.timestamps null: false
+    end
+    # Use both model and DB-level constraints for consistency while scaling horizontally
+    add_index :minter_states, :namespace, unique: true
+  end
+end