miss_hannigan 0.1.0

checksums.yaml

@@ -0,0 +1,7 @@
+---
+SHA256:
+  metadata.gz: 28c9793e4a1c2d84ab1e77478eec6c6df117a63ba75651ed231414ac9744e46b
+  data.tar.gz: fbc963f9e14e9bd7d16f0b00dd7136e1fefb29897cfdd2df74bd6b6cad9af239
+SHA512:
+  metadata.gz: 0e304742dfaac4db849f9659d3c234f4bfd4d6440a23b451df6578987092b39ef189dbfbb399103938274d8be397dd877017f9429b62e83817dccf5acb9a7a30
+  data.tar.gz: 6965f0f0a3fdcb57977e5cfbc13969341293fcdfdf1b9dd4c4c761f7dc0ee798d05d9476dd1c6143e18ddb34e7958289e392ea1b92cd1cbc674671e2967143e8

data/MIT-LICENSE

@@ -0,0 +1,20 @@
+Copyright 2020 n8
+
+Permission is hereby granted, free of charge, to any person obtaining
+a copy of this software and associated documentation files (the
+"Software"), to deal in the Software without restriction, including
+without limitation the rights to use, copy, modify, merge, publish,
+distribute, sublicense, and/or sell copies of the Software, and to
+permit persons to whom the Software is furnished to do so, subject to
+the following conditions:
+
+The above copyright notice and this permission notice shall be
+included in all copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
+MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE
+LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION
+OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION
+WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.

data/README.md

@@ -0,0 +1,148 @@
+# Miss Hannigan
+
+> Daddy Warbucks : You lock the orphans in the closet.
+>
+> Miss Hannigan : They love it!
+
+## What?
+
+miss_hannigan provides an alternative (and in some cases, better) way to do cascading deletes/destroys in Rails. With it, you can now define a :dependent has_many behavior of :nullify_then_purge which will quickly and synchronously nullify (orphan) children from their parent, and then asynchronously purge those child records (the orphans) from the database. 
+
+```
+class Parent < ApplicationRecord
+    has_many :children, dependent: :nullify_then_purge
+end
+```
+
+## Installation
+
+1. Add `gem 'miss_hannigan'` to your Gemfile.
+2. Run `bundle install`.
+3. Restart your server
+4. Add the new dependent option to your has_many relationships: 
+
+```
+has_many :children, dependent: :nullify_then_purge
+```
+
+Note: If your `child` has a foreign_key relationship with the `parent`, you'll need to make sure the foreign_key in the `child` allows for nulls. For example, you might have to create migrations like this: 
+
+```
+class RemoveNullKeyConstraint < ActiveRecord::Migration[6.0]
+  def change
+    change_column_null(:children, :parent_id, true)
+  end
+end
+```
+
+miss_hannigan will raise an error if the foreign_key isn't configured appropriately. 
+
+miss_hannigan also assumes you're using ActiveJob with an active queue system in place - that's how orphans get asynchronously destroyed after all. 
+
+## Why?
+
+Whether you are a Rails expert or just getting started with the framework, you've most likely had to make smart choices on how cascading deletes work in your system. And often in large systems, you're forced with a compromise...
+
+To quickly catch beginners up, Rails has some great tooling to deal with parent-child relationships using has_many: 
+
+```
+class Parent < ApplicationRecord
+    has_many :children
+end
+```
+
+By default, what happens to `children` when you delete an instance of Parent? Nothing. Children just sit tight or in our more typical vernacular, they're orphaned. 
+
+Normally, you consider two options then: destroy the children, or delete the children. 
+
+### dependent: :destroy
+
+Destroying the children is ideal. You do that by setting `dependent: :destroy` on the has_many relationship. Like so: 
+
+```
+class Parent ApplicationRecord
+    has_many :children, dependent: :destroy
+end
+```
+
+Rails, when attempting to destroy an instance of the Parent, will also iteratively go through each child of the parent calling destroy on the child. The benefit of this is that any callbacks and validation on those children are given their day in the sun. If you're using a foreign_key constraint between Parent -> Child, this path will also keep your DB happy. (The children are deleted first, then the parent, avoiding the DB complaining about a foreign key being invalid.)
+
+But the main drawback is that destroying a ton of children can be time consuming, especially if those children have their own children (and those have more children, etc.). So time consuming that you simply can't have a user wait that long do even do a delete. And with some hosting platforms, the deletes won't even work as you'll face Timeout errors instead. 
+
+So, many of us reach for the much faster option of using a `:delete_all ` dependency. 
+
+### dependent: :delete_all
+
+Going this route, Rails will delete all children of a parent in a single SQL call without going through the Rails instantiations and callbacks.
+
+```
+class Parent ApplicationRecord
+    has_many :children, dependent: :delete_all
+end
+```
+
+However, `:delete` has plenty of problems because it doesn't go through the typical Rails destroy. 
+
+For example, you can't automatically do any post-destroy cleanup (e.g. 3rd party API calls) when those children are destroyed.
+
+And you can't use this approach if you are using foreign key constraints in your DB: 
+
+![](https://github.com/sutrolabs/miss_hannigan/blob/master/foreign_key_error_example.png?raw=true)
+
+Another catch is that if you have a Parent -> Child -> Grandchild relationship, and it uses `dependent: :delete_all` down the tree, destroying a Parent, will stop with deleting the Children. Grandchildren won't even get deleted/destroyed. 
+
+------------
+
+Here at Census this became a problem. We have quite a lot of children of parent objects. And children have children have children... We had users experiencing timeouts during deletions. 
+
+Well, we can't reach for dependent: :delete_all since we have a multiple layered hierarchy of objects that all need destroying. We also have foreign_key constraints we'd like to keep using. 
+
+So what do we do if neither of these approaches work for us? 
+
+We use an "orphan then later purge" approach. Which has some of the best of both :destroy and :delete_all worlds. 
+
+dependent has a nifty but less often mentioned option of :nullify. 
+
+```
+class Parent < ApplicationRecord
+    has_many :children, dependent: :nullify
+end
+```
+
+Using :nullify will simply issue a single UPDATE statement setting children's parent_id to NULL. Which is super fast. 
+
+This sets up a bunch of orphaned children now that can easily be cleaned up in an asynchronous purge. 
+
+And now because we're destroying Children here, the normal callbacks are run also allowing Rails to cleanup and destroy GrandChildren. 
+
+Fast AND thorough. 
+
+So we wrapped that pattern together into miss_hannigan: 
+
+```
+class Parent < ApplicationRecord
+    has_many :children, dependent: :nullify_then_purge
+end
+```
+
+## Alternatives 
+
+It's worth noting there are other strategies like allowing your DB handle its own cascading deletes. For example, adding foreign keys on a Postgres DB from a Rails migration like so: 
+
+```
+add_foreign_key "children", "parents", on_delete: :cascade
+```
+
+Doing that will have Postgres automatically delete children rows when a parent is deleted. But that removes itself from Rails-land where we have other cleanup hooks and tooling we'd like to keep running. 
+
+Another alternative would be to use a pattern like acts_as_paranoid to "soft delete" a parent record and later destroy it asynchronously. 
+
+
+Feedback
+--------
+[Source code available on Github](https://github.com/sutrolabs/miss_hannigan). Feedback and pull requests are greatly appreciated. Let us know if we can improve this.
+
+
+From
+-----------
+:wave: The folks at [Census](http://getcensus.com) originally put this together. Have data? We'll sync your data warehouse with your CRM and the customer success apps critical to your team. 

data/Rakefile

@@ -0,0 +1,27 @@
+begin
+  require 'bundler/setup'
+rescue LoadError
+  puts 'You must `gem install bundler` and `bundle install` to run rake tasks'
+end
+
+require 'rdoc/task'
+
+RDoc::Task.new(:rdoc) do |rdoc|
+  rdoc.rdoc_dir = 'rdoc'
+  rdoc.title    = 'MissHannigan'
+  rdoc.options << '--line-numbers'
+  rdoc.rdoc_files.include('README.md')
+  rdoc.rdoc_files.include('lib/**/*.rb')
+end
+
+require 'bundler/gem_tasks'
+
+require 'rake/testtask'
+
+Rake::TestTask.new(:test) do |t|
+  t.libs << 'test'
+  t.pattern = 'test/**/*_test.rb'
+  t.verbose = false
+end
+
+task default: :test

data/lib/miss_hannigan.rb

@@ -0,0 +1,2 @@
+require "miss_hannigan/miss_hannigan"
+require 'miss_hannigan/railtie' 

data/lib/miss_hannigan/miss_hannigan.rb

@@ -0,0 +1,48 @@
+module MissHannigan
+  extend ActiveSupport::Concern
+
+  module ClassMethods
+
+    def has_many(name, scope = nil, **options, &extension) 
+      nullify_then_purge = false
+
+      # we're really just relying on :nullify. so just return our dependent option to that
+      if options[:dependent] == :nullify_then_purge
+        nullify_then_purge = true
+        options[:dependent] = :nullify
+      end
+
+      # get our normal has_many reflection to get setup
+      reflection = super
+
+      if nullify_then_purge
+
+        # has the details of the relation to Child
+        reflection_details = reflection[name.to_s]
+
+        # I bet folks are going to forget to do the migration of foreign_keys to accept null. Rails defaults 
+        # to not allow null.
+        if !reflection_details.klass.columns.find { |c| c.name == reflection_details.foreign_key }.null
+          raise "The foreign key must be nullable to support MissHannigan. You should create a migration to: 
+            change_column_null :#{name.to_s}, :#{reflection_details.foreign_key}, true"
+        end
+        
+        after_destroy do |this_object|
+          CleanupJob.perform_later(reflection_details.klass.to_s, reflection_details.foreign_key)
+        end
+      end
+
+      return reflection
+    end
+  end
+
+  class CleanupJob < ActiveJob::Base
+    queue_as :default
+    
+    def perform(klass_string, parent_foreign_key)
+      klass = klass_string.constantize
+
+      klass.where(parent_foreign_key => nil).find_each(&:destroy)
+    end
+  end
+end

data/lib/miss_hannigan/railtie.rb

@@ -0,0 +1,11 @@
+require 'rails'
+
+module MissHannigan
+  class Railtie < Rails::Railtie
+    initializer 'miss_hannigan.initialize' do
+      ActiveSupport.on_load(:active_record) do
+        ActiveRecord::Base.send :include, MissHannigan
+      end
+    end
+  end
+end

data/lib/miss_hannigan/version.rb

@@ -0,0 +1,3 @@
+module MissHannigan
+  VERSION = '0.1.0'
+end

data/lib/tasks/miss_hannigan_tasks.rake

@@ -0,0 +1,4 @@
+# desc "Explaining what the task does"
+# task :miss_hannigan do
+#   # Task goes here
+# end

metadata

@@ -0,0 +1,85 @@
+--- !ruby/object:Gem::Specification
+name: miss_hannigan
+version: !ruby/object:Gem::Version
+  version: 0.1.0
+platform: ruby
+authors:
+- n8
+- bradleybuda
+- avaynshtok
+- sean-lynch
+- davehughes
+- bjabes
+autorequire: 
+bindir: bin
+cert_chain: []
+date: 2020-02-28 00:00:00.000000000 Z
+dependencies:
+- !ruby/object:Gem::Dependency
+  name: rails
+  requirement: !ruby/object:Gem::Requirement
+    requirements:
+    - - ">="
+      - !ruby/object:Gem::Version
+        version: '5.1'
+  type: :runtime
+  prerelease: false
+  version_requirements: !ruby/object:Gem::Requirement
+    requirements:
+    - - ">="
+      - !ruby/object:Gem::Version
+        version: '5.1'
+- !ruby/object:Gem::Dependency
+  name: sqlite3
+  requirement: !ruby/object:Gem::Requirement
+    requirements:
+    - - ">="
+      - !ruby/object:Gem::Version
+        version: '0'
+  type: :development
+  prerelease: false
+  version_requirements: !ruby/object:Gem::Requirement
+    requirements:
+    - - ">="
+      - !ruby/object:Gem::Version
+        version: '0'
+description: If neither :destroy or :delete_all work for you when deleting children
+  in Rails, maybe this is the right combination for you.
+email:
+- nate.kontny@gmail.com
+executables: []
+extensions: []
+extra_rdoc_files: []
+files:
+- MIT-LICENSE
+- README.md
+- Rakefile
+- lib/miss_hannigan.rb
+- lib/miss_hannigan/miss_hannigan.rb
+- lib/miss_hannigan/railtie.rb
+- lib/miss_hannigan/version.rb
+- lib/tasks/miss_hannigan_tasks.rake
+homepage: https://rubygems.org/gems/miss_hannigan
+licenses:
+- MIT
+metadata: {}
+post_install_message: 
+rdoc_options: []
+require_paths:
+- lib
+required_ruby_version: !ruby/object:Gem::Requirement
+  requirements:
+  - - ">="
+    - !ruby/object:Gem::Version
+      version: '0'
+required_rubygems_version: !ruby/object:Gem::Requirement
+  requirements:
+  - - ">="
+    - !ruby/object:Gem::Version
+      version: '0'
+requirements: []
+rubygems_version: 3.1.2
+signing_key: 
+specification_version: 4
+summary: An alternative way to do cascading deletes in Rails.
+test_files: []