miss_hannigan 0.1.1 → 0.1.2

checksums.yaml

@@ -1,7 +1,7 @@
 ---
 SHA256:
-  metadata.gz: 703b7799f10817fa5d27a8b8627f11223f138decff67f46352881e9fd0cd47b4
-  data.tar.gz: f8d9ca9e92e88e80de30a110cd1d115b5e8d98560735c7256ff1cefb2bb98b02
+  metadata.gz: 3978b43b61c215d99d63cda3090f4112ada5899f5c5a1a633f397c12702fce29
+  data.tar.gz: bbd50537d9be7187e700cca4b5220f5202d43f08cb558fa02fc5896c3a80109d
 SHA512:
-  metadata.gz: a7f287cbe1d13a6c34c81492a995a1556855f34f5bd7fea7de8d0c8d439db7d715a431cf6a0a1298733e0d78a805eab7726ed1b1f30788f3c4a91db4acabe948
-  data.tar.gz: 7cdac48b599c565a0e79a75b6043f60d3f55e234696f95d08c8073d6d1c82b858019960df6768a7d08b1feb90f3ed3d5014ef403b0fa8353661aeb89facfb8dc
+  metadata.gz: 6161f50401dd02989f211355bc30a13b7e6db01a6f981c43fd9889cdb2ea4c3de79059bdd3bdf3ae0671044575ffcb0d504db3449b343400a0326910d9cdf99e
+  data.tar.gz: f813c60fbf646f76c20952ce489b0c7da2757c5b7d2198d56742f663d8128c458918279b7e50c03563f8b3d5e0eba90e52e2c5fcef33ce61463780711bee880b

data/README.md

@@ -6,11 +6,11 @@
 
 ## 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. 
+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
+  has_many :children, dependent: :nullify_then_purge
 end
 ```
 
@@ -19,13 +19,13 @@ end
 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: 
+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: 
+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]
@@ -35,41 +35,41 @@ class RemoveNullKeyConstraint < ActiveRecord::Migration[6.0]
 end
 ```
 
-miss_hannigan will raise an error if the foreign_key isn't configured appropriately. 
+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. 
+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: 
+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
+  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. 
+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. 
+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: 
+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
+  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. 
+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. 
+So, many of us reach for the much faster option of using a `:delete_all ` dependency.
 
 ### dependent: :delete_all
 
@@ -77,65 +77,65 @@ Going this route, Rails will delete all children of a parent in a single SQL cal
 
 ```
 class Parent ApplicationRecord
-    has_many :children, dependent: :delete_all
+  has_many :children, dependent: :delete_all
 end
 ```
 
-However, `:delete` has plenty of problems because it doesn't go through the typical Rails destroy. 
+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: 
+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. 
+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. 
+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. 
+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? 
+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. 
+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. 
+dependent has a nifty but less often mentioned option of :nullify.
 
 ```
 class Parent < ApplicationRecord
-    has_many :children, dependent: :nullify
+  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. 
+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. 
+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. 
+And now because we're destroying Children here, the normal callbacks are run also allowing Rails to cleanup and destroy GrandChildren.
 
-Fast AND thorough. 
+Fast AND thorough.
 
-So we wrapped that pattern together into miss_hannigan: 
+So we wrapped that pattern together into miss_hannigan:
 
 ```
 class Parent < ApplicationRecord
-    has_many :children, dependent: :nullify_then_purge
+  has_many :children, dependent: :nullify_then_purge
 end
 ```
 
-## Alternatives 
+## 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: 
+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. 
+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. 
+Another alternative would be to use a pattern like acts_as_paranoid to "soft delete" a parent record and later destroy it asynchronously.
 
 
 Feedback
@@ -145,4 +145,4 @@ Feedback
 
 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. 
+: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/lib/miss_hannigan/miss_hannigan.rb

@@ -2,43 +2,49 @@ module MissHannigan
   extend ActiveSupport::Concern
 
   module ClassMethods
+    def has_many(name, scope = nil, **options, &extension)
+      nullify_then_purge = detect_nullify_then_purge(options)
+      super.tap do |reflection|
+        connect_nullify_then_purge(reflection, name) if nullify_then_purge
+      end
+    end
 
-    def has_many(name, scope = nil, **options, &extension) 
-      nullify_then_purge = false
+    def has_one(name, scope = nil, **options, &extension)
+      nullify_then_purge = detect_nullify_then_purge(options)
+      super.tap do |reflection|
+        connect_nullify_then_purge(reflection, name) if nullify_then_purge
+      end
+    end
 
-      # we're really just relying on :nullify. so just return our dependent option to that
+    def detect_nullify_then_purge(options)
       if options[:dependent] == :nullify_then_purge
-        nullify_then_purge = true
         options[:dependent] = :nullify
+        true
+      else
+        false
       end
+    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]
+    def connect_nullify_then_purge(reflection, name)
+      # 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
+      # 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
 
-      return reflection
+      after_destroy do |this_object|
+        CleanupJob.perform_later(reflection_details.klass.to_s, reflection_details.foreign_key)
+      end
     end
   end
 
   class CleanupJob < ActiveJob::Base
     queue_as :default
-    
+
     def perform(klass_string, parent_foreign_key)
       klass = klass_string.constantize
 

data/lib/miss_hannigan/version.rb

@@ -1,3 +1,3 @@
 module MissHannigan
-  VERSION = '0.1.1'
+  VERSION = '0.1.2'
 end

metadata

@@ -1,7 +1,7 @@
 --- !ruby/object:Gem::Specification
 name: miss_hannigan
 version: !ruby/object:Gem::Version
-  version: 0.1.1
+  version: 0.1.2
 platform: ruby
 authors:
 - n8
@@ -13,7 +13,7 @@ authors:
 autorequire: 
 bindir: bin
 cert_chain: []
-date: 2020-02-28 00:00:00.000000000 Z
+date: 2020-08-24 00:00:00.000000000 Z
 dependencies:
 - !ruby/object:Gem::Dependency
   name: rails