duck_record 0.0.1

data/lib/duck_record/base.rb

@@ -0,0 +1,296 @@
+require 'yaml'
+require 'active_support/benchmarkable'
+require 'active_support/dependencies'
+require 'active_support/descendants_tracker'
+require 'active_support/time'
+require 'active_support/core_ext/module/attribute_accessors'
+require 'active_support/core_ext/array/extract_options'
+require 'active_support/core_ext/hash/deep_merge'
+require 'active_support/core_ext/hash/slice'
+require 'active_support/core_ext/hash/transform_values'
+require 'active_support/core_ext/string/behavior'
+require 'active_support/core_ext/kernel/singleton_class'
+require 'active_support/core_ext/module/introspection'
+require 'active_support/core_ext/object/duplicable'
+require 'active_support/core_ext/class/subclasses'
+require 'duck_record/define_callbacks'
+require 'duck_record/errors'
+require 'duck_record/attributes'
+
+module DuckRecord #:nodoc:
+  # = Active Record
+  #
+  # Active Record objects don't specify their attributes directly, but rather infer them from
+  # the table definition with which they're linked. Adding, removing, and changing attributes
+  # and their type is done directly in the database. Any change is instantly reflected in the
+  # Active Record objects. The mapping that binds a given Active Record class to a certain
+  # database table will happen automatically in most common cases, but can be overwritten for the uncommon ones.
+  #
+  # See the mapping rules in table_name and the full example in link:files/activerecord/README_rdoc.html for more insight.
+  #
+  # == Creation
+  #
+  # Active Records accept constructor parameters either in a hash or as a block. The hash
+  # method is especially useful when you're receiving the data from somewhere else, like an
+  # HTTP request. It works like this:
+  #
+  #   user = User.new(name: 'David', occupation: 'Code Artist')
+  #   user.name # => 'David'
+  #
+  # You can also use block initialization:
+  #
+  #   user = User.new do |u|
+  #     u.name = 'David'
+  #     u.occupation = 'Code Artist'
+  #   end
+  #
+  # And of course you can just create a bare object and specify the attributes after the fact:
+  #
+  #   user = User.new
+  #   user.name = 'David'
+  #   user.occupation = 'Code Artist'
+  #
+  # == Conditions
+  #
+  # Conditions can either be specified as a string, array, or hash representing the WHERE-part of an SQL statement.
+  # The array form is to be used when the condition input is tainted and requires sanitization. The string form can
+  # be used for statements that don't involve tainted data. The hash form works much like the array form, except
+  # only equality and range is possible. Examples:
+  #
+  #   class User < DuckRecord::Base
+  #     def self.authenticate_unsafely(user_name, password)
+  #       where('user_name = '#{user_name}' AND password = '#{password}'').first
+  #     end
+  #
+  #     def self.authenticate_safely(user_name, password)
+  #       where('user_name = ? AND password = ?', user_name, password).first
+  #     end
+  #
+  #     def self.authenticate_safely_simply(user_name, password)
+  #       where(user_name: user_name, password: password).first
+  #     end
+  #   end
+  #
+  # The <tt>authenticate_unsafely</tt> method inserts the parameters directly into the query
+  # and is thus susceptible to SQL-injection attacks if the <tt>user_name</tt> and +password+
+  # parameters come directly from an HTTP request. The <tt>authenticate_safely</tt> and
+  # <tt>authenticate_safely_simply</tt> both will sanitize the <tt>user_name</tt> and +password+
+  # before inserting them in the query, which will ensure that an attacker can't escape the
+  # query and fake the login (or worse).
+  #
+  # When using multiple parameters in the conditions, it can easily become hard to read exactly
+  # what the fourth or fifth question mark is supposed to represent. In those cases, you can
+  # resort to named bind variables instead. That's done by replacing the question marks with
+  # symbols and supplying a hash with values for the matching symbol keys:
+  #
+  #   Company.where(
+  #     'id = :id AND name = :name AND division = :division AND created_at > :accounting_date',
+  #     { id: 3, name: '37signals', division: 'First', accounting_date: '2005-01-01' }
+  #   ).first
+  #
+  # Similarly, a simple hash without a statement will generate conditions based on equality with the SQL AND
+  # operator. For instance:
+  #
+  #   Student.where(first_name: 'Harvey', status: 1)
+  #   Student.where(params[:student])
+  #
+  # A range may be used in the hash to use the SQL BETWEEN operator:
+  #
+  #   Student.where(grade: 9..12)
+  #
+  # An array may be used in the hash to use the SQL IN operator:
+  #
+  #   Student.where(grade: [9,11,12])
+  #
+  # When joining tables, nested hashes or keys written in the form 'table_name.column_name'
+  # can be used to qualify the table name of a particular condition. For instance:
+  #
+  #   Student.joins(:schools).where(schools: { category: 'public' })
+  #   Student.joins(:schools).where('schools.category' => 'public' )
+  #
+  # == Overwriting default accessors
+  #
+  # All column values are automatically available through basic accessors on the Active Record
+  # object, but sometimes you want to specialize this behavior. This can be done by overwriting
+  # the default accessors (using the same name as the attribute) and calling
+  # +super+ to actually change things.
+  #
+  #   class Song < DuckRecord::Base
+  #     # Uses an integer of seconds to hold the length of the song
+  #
+  #     def length=(minutes)
+  #       super(minutes.to_i * 60)
+  #     end
+  #
+  #     def length
+  #       super / 60
+  #     end
+  #   end
+  #
+  # == Attribute query methods
+  #
+  # In addition to the basic accessors, query methods are also automatically available on the Active Record object.
+  # Query methods allow you to test whether an attribute value is present.
+  # Additionally, when dealing with numeric values, a query method will return false if the value is zero.
+  #
+  # For example, an Active Record User with the <tt>name</tt> attribute has a <tt>name?</tt> method that you can call
+  # to determine whether the user has a name:
+  #
+  #   user = User.new(name: 'David')
+  #   user.name? # => true
+  #
+  #   anonymous = User.new(name: '')
+  #   anonymous.name? # => false
+  #
+  # == Accessing attributes before they have been typecasted
+  #
+  # Sometimes you want to be able to read the raw attribute data without having the column-determined
+  # typecast run its course first. That can be done by using the <tt><attribute>_before_type_cast</tt>
+  # accessors that all attributes have. For example, if your Account model has a <tt>balance</tt> attribute,
+  # you can call <tt>account.balance_before_type_cast</tt> or <tt>account.id_before_type_cast</tt>.
+  #
+  # This is especially useful in validation situations where the user might supply a string for an
+  # integer field and you want to display the original string back in an error message. Accessing the
+  # attribute normally would typecast the string to 0, which isn't what you want.
+  #
+  # == Dynamic attribute-based finders
+  #
+  # Dynamic attribute-based finders are a mildly deprecated way of getting (and/or creating) objects
+  # by simple queries without turning to SQL. They work by appending the name of an attribute
+  # to <tt>find_by_</tt> like <tt>Person.find_by_user_name</tt>.
+  # Instead of writing <tt>Person.find_by(user_name: user_name)</tt>, you can use
+  # <tt>Person.find_by_user_name(user_name)</tt>.
+  #
+  # It's possible to add an exclamation point (!) on the end of the dynamic finders to get them to raise an
+  # DuckRecord::RecordNotFound error if they do not return any records,
+  # like <tt>Person.find_by_last_name!</tt>.
+  #
+  # It's also possible to use multiple attributes in the same <tt>find_by_</tt> by separating them with
+  # '_and_'.
+  #
+  #  Person.find_by(user_name: user_name, password: password)
+  #  Person.find_by_user_name_and_password(user_name, password) # with dynamic finder
+  #
+  # It's even possible to call these dynamic finder methods on relations and named scopes.
+  #
+  #   Payment.order('created_on').find_by_amount(50)
+  #
+  # == Saving arrays, hashes, and other non-mappable objects in text columns
+  #
+  # Active Record can serialize any object in text columns using YAML. To do so, you must
+  # specify this with a call to the class method
+  # {serialize}[rdoc-ref:AttributeMethods::Serialization::ClassMethods#serialize].
+  # This makes it possible to store arrays, hashes, and other non-mappable objects without doing
+  # any additional work.
+  #
+  #   class User < DuckRecord::Base
+  #     serialize :preferences
+  #   end
+  #
+  #   user = User.create(preferences: { 'background' => 'black', 'display' => large })
+  #   User.find(user.id).preferences # => { 'background' => 'black', 'display' => large }
+  #
+  # You can also specify a class option as the second parameter that'll raise an exception
+  # if a serialized object is retrieved as a descendant of a class not in the hierarchy.
+  #
+  #   class User < DuckRecord::Base
+  #     serialize :preferences, Hash
+  #   end
+  #
+  #   user = User.create(preferences: %w( one two three ))
+  #   User.find(user.id).preferences    # raises SerializationTypeMismatch
+  #
+  # When you specify a class option, the default value for that attribute will be a new
+  # instance of that class.
+  #
+  #   class User < DuckRecord::Base
+  #     serialize :preferences, OpenStruct
+  #   end
+  #
+  #   user = User.new
+  #   user.preferences.theme_color = 'red'
+  #
+  #
+  # == Single table inheritance
+  #
+  # Active Record allows inheritance by storing the name of the class in a
+  # column that is named 'type' by default. See DuckRecord::Inheritance for
+  # more details.
+  #
+  # == Connection to multiple databases in different models
+  #
+  # Connections are usually created through
+  # {DuckRecord::Base.establish_connection}[rdoc-ref:ConnectionHandling#establish_connection] and retrieved
+  # by DuckRecord::Base.connection. All classes inheriting from DuckRecord::Base will use this
+  # connection. But you can also set a class-specific connection. For example, if Course is an
+  # DuckRecord::Base, but resides in a different database, you can just say <tt>Course.establish_connection</tt>
+  # and Course and all of its subclasses will use this connection instead.
+  #
+  # This feature is implemented by keeping a connection pool in DuckRecord::Base that is
+  # a hash indexed by the class. If a connection is requested, the
+  # {DuckRecord::Base.retrieve_connection}[rdoc-ref:ConnectionHandling#retrieve_connection] method
+  # will go up the class-hierarchy until a connection is found in the connection pool.
+  #
+  # == Exceptions
+  #
+  # * DuckRecordError - Generic error class and superclass of all other errors raised by Active Record.
+  # * AdapterNotSpecified - The configuration hash used in
+  #   {DuckRecord::Base.establish_connection}[rdoc-ref:ConnectionHandling#establish_connection]
+  #   didn't include an <tt>:adapter</tt> key.
+  # * AdapterNotFound - The <tt>:adapter</tt> key used in
+  #   {DuckRecord::Base.establish_connection}[rdoc-ref:ConnectionHandling#establish_connection]
+  #   specified a non-existent adapter
+  #   (or a bad spelling of an existing one).
+  # * AssociationTypeMismatch - The object assigned to the association wasn't of the type
+  #   specified in the association definition.
+  # * AttributeAssignmentError - An error occurred while doing a mass assignment through the
+  #   {DuckRecord::Base#attributes=}[rdoc-ref:AttributeAssignment#attributes=] method.
+  #   You can inspect the +attribute+ property of the exception object to determine which attribute
+  #   triggered the error.
+  # * ConnectionNotEstablished - No connection has been established.
+  #   Use {DuckRecord::Base.establish_connection}[rdoc-ref:ConnectionHandling#establish_connection] before querying.
+  # * MultiparameterAssignmentErrors - Collection of errors that occurred during a mass assignment using the
+  #   {DuckRecord::Base#attributes=}[rdoc-ref:AttributeAssignment#attributes=] method.
+  #   The +errors+ property of this exception contains an array of
+  #   AttributeAssignmentError
+  #   objects that should be inspected to determine which attributes triggered the errors.
+  # * RecordInvalid - raised by {DuckRecord::Base#save!}[rdoc-ref:Persistence#save!] and
+  #   {DuckRecord::Base.create!}[rdoc-ref:Persistence::ClassMethods#create!]
+  #   when the record is invalid.
+  # * RecordNotFound - No record responded to the {DuckRecord::Base.find}[rdoc-ref:FinderMethods#find] method.
+  #   Either the row with the given ID doesn't exist or the row didn't meet the additional restrictions.
+  #   Some {DuckRecord::Base.find}[rdoc-ref:FinderMethods#find] calls do not raise this exception to signal
+  #   nothing was found, please check its documentation for further details.
+  # * SerializationTypeMismatch - The serialized object wasn't of the class specified as the second parameter.
+  # * StatementInvalid - The database server rejected the SQL statement. The precise error is added in the message.
+  #
+  # *Note*: The attributes listed are class-level attributes (accessible from both the class and instance level).
+  # So it's possible to assign a logger to the class through <tt>Base.logger=</tt> which will then be used by all
+  # instances in the current object space.
+  class Base
+    extend ActiveModel::Naming
+
+    extend ActiveSupport::Benchmarkable
+    extend ActiveSupport::DescendantsTracker
+
+    extend Translation
+
+    include Core
+    include ModelSchema
+    include Inheritance
+    include AttributeAssignment
+    include ActiveModel::Conversion
+    include Validations
+    include Attributes
+    include DefineCallbacks
+    include AttributeMethods
+    include Callbacks
+    include Serialization
+
+    def persisted?
+      false
+    end
+  end
+
+  ActiveSupport.run_load_hooks(:duck_record, Base)
+end

data/lib/duck_record/callbacks.rb

@@ -0,0 +1,324 @@
+module DuckRecord
+  # = Active Record \Callbacks
+  #
+  # \Callbacks are hooks into the life cycle of an Active Record object that allow you to trigger logic
+  # before or after an alteration of the object state. This can be used to make sure that associated and
+  # dependent objects are deleted when {DuckRecord::Base#destroy}[rdoc-ref:Persistence#destroy] is called (by overwriting +before_destroy+) or
+  # to massage attributes before they're validated (by overwriting +before_validation+).
+  # As an example of the callbacks initiated, consider the {DuckRecord::Base#save}[rdoc-ref:Persistence#save] call for a new record:
+  #
+  # * (-) <tt>save</tt>
+  # * (-) <tt>valid</tt>
+  # * (1) <tt>before_validation</tt>
+  # * (-) <tt>validate</tt>
+  # * (2) <tt>after_validation</tt>
+  # * (3) <tt>before_save</tt>
+  # * (4) <tt>before_create</tt>
+  # * (-) <tt>create</tt>
+  # * (5) <tt>after_create</tt>
+  # * (6) <tt>after_save</tt>
+  # * (7) <tt>after_commit</tt>
+  #
+  # Also, an <tt>after_rollback</tt> callback can be configured to be triggered whenever a rollback is issued.
+  # Check out DuckRecord::Transactions for more details about <tt>after_commit</tt> and
+  # <tt>after_rollback</tt>.
+  #
+  # Additionally, an <tt>after_touch</tt> callback is triggered whenever an
+  # object is touched.
+  #
+  # Lastly an <tt>after_find</tt> and <tt>after_initialize</tt> callback is triggered for each object that
+  # is found and instantiated by a finder, with <tt>after_initialize</tt> being triggered after new objects
+  # are instantiated as well.
+  #
+  # There are nineteen callbacks in total, which give you immense power to react and prepare for each state in the
+  # Active Record life cycle. The sequence for calling {DuckRecord::Base#save}[rdoc-ref:Persistence#save] for an existing record is similar,
+  # except that each <tt>_create</tt> callback is replaced by the corresponding <tt>_update</tt> callback.
+  #
+  # Examples:
+  #   class CreditCard < DuckRecord::Base
+  #     # Strip everything but digits, so the user can specify "555 234 34" or
+  #     # "5552-3434" and both will mean "55523434"
+  #     before_validation(on: :create) do
+  #       self.number = number.gsub(/[^0-9]/, "") if attribute_present?("number")
+  #     end
+  #   end
+  #
+  #   class Subscription < DuckRecord::Base
+  #     before_create :record_signup
+  #
+  #     private
+  #       def record_signup
+  #         self.signed_up_on = Date.today
+  #       end
+  #   end
+  #
+  #   class Firm < DuckRecord::Base
+  #     # Disables access to the system, for associated clients and people when the firm is destroyed
+  #     before_destroy { |record| Person.where(firm_id: record.id).update_all(access: 'disabled')   }
+  #     before_destroy { |record| Client.where(client_of: record.id).update_all(access: 'disabled') }
+  #   end
+  #
+  # == Inheritable callback queues
+  #
+  # Besides the overwritable callback methods, it's also possible to register callbacks through the
+  # use of the callback macros. Their main advantage is that the macros add behavior into a callback
+  # queue that is kept intact down through an inheritance hierarchy.
+  #
+  #   class Topic < DuckRecord::Base
+  #     before_destroy :destroy_author
+  #   end
+  #
+  #   class Reply < Topic
+  #     before_destroy :destroy_readers
+  #   end
+  #
+  # Now, when <tt>Topic#destroy</tt> is run only +destroy_author+ is called. When <tt>Reply#destroy</tt> is
+  # run, both +destroy_author+ and +destroy_readers+ are called. Contrast this to the following situation
+  # where the +before_destroy+ method is overridden:
+  #
+  #   class Topic < DuckRecord::Base
+  #     def before_destroy() destroy_author end
+  #   end
+  #
+  #   class Reply < Topic
+  #     def before_destroy() destroy_readers end
+  #   end
+  #
+  # In that case, <tt>Reply#destroy</tt> would only run +destroy_readers+ and _not_ +destroy_author+.
+  # So, use the callback macros when you want to ensure that a certain callback is called for the entire
+  # hierarchy, and use the regular overwritable methods when you want to leave it up to each descendant
+  # to decide whether they want to call +super+ and trigger the inherited callbacks.
+  #
+  # *IMPORTANT:* In order for inheritance to work for the callback queues, you must specify the
+  # callbacks before specifying the associations. Otherwise, you might trigger the loading of a
+  # child before the parent has registered the callbacks and they won't be inherited.
+  #
+  # == Types of callbacks
+  #
+  # There are four types of callbacks accepted by the callback macros: Method references (symbol), callback objects,
+  # inline methods (using a proc), and inline eval methods (using a string). Method references and callback objects
+  # are the recommended approaches, inline methods using a proc are sometimes appropriate (such as for
+  # creating mix-ins), and inline eval methods are deprecated.
+  #
+  # The method reference callbacks work by specifying a protected or private method available in the object, like this:
+  #
+  #   class Topic < DuckRecord::Base
+  #     before_destroy :delete_parents
+  #
+  #     private
+  #       def delete_parents
+  #         self.class.delete_all "parent_id = #{id}"
+  #       end
+  #   end
+  #
+  # The callback objects have methods named after the callback called with the record as the only parameter, such as:
+  #
+  #   class BankAccount < DuckRecord::Base
+  #     before_save      EncryptionWrapper.new
+  #     after_save       EncryptionWrapper.new
+  #     after_initialize EncryptionWrapper.new
+  #   end
+  #
+  #   class EncryptionWrapper
+  #     def before_save(record)
+  #       record.credit_card_number = encrypt(record.credit_card_number)
+  #     end
+  #
+  #     def after_save(record)
+  #       record.credit_card_number = decrypt(record.credit_card_number)
+  #     end
+  #
+  #     alias_method :after_initialize, :after_save
+  #
+  #     private
+  #       def encrypt(value)
+  #         # Secrecy is committed
+  #       end
+  #
+  #       def decrypt(value)
+  #         # Secrecy is unveiled
+  #       end
+  #   end
+  #
+  # So you specify the object you want messaged on a given callback. When that callback is triggered, the object has
+  # a method by the name of the callback messaged. You can make these callbacks more flexible by passing in other
+  # initialization data such as the name of the attribute to work with:
+  #
+  #   class BankAccount < DuckRecord::Base
+  #     before_save      EncryptionWrapper.new("credit_card_number")
+  #     after_save       EncryptionWrapper.new("credit_card_number")
+  #     after_initialize EncryptionWrapper.new("credit_card_number")
+  #   end
+  #
+  #   class EncryptionWrapper
+  #     def initialize(attribute)
+  #       @attribute = attribute
+  #     end
+  #
+  #     def before_save(record)
+  #       record.send("#{@attribute}=", encrypt(record.send("#{@attribute}")))
+  #     end
+  #
+  #     def after_save(record)
+  #       record.send("#{@attribute}=", decrypt(record.send("#{@attribute}")))
+  #     end
+  #
+  #     alias_method :after_initialize, :after_save
+  #
+  #     private
+  #       def encrypt(value)
+  #         # Secrecy is committed
+  #       end
+  #
+  #       def decrypt(value)
+  #         # Secrecy is unveiled
+  #       end
+  #   end
+  #
+  # == <tt>before_validation*</tt> returning statements
+  #
+  # If the +before_validation+ callback throws +:abort+, the process will be
+  # aborted and {DuckRecord::Base#save}[rdoc-ref:Persistence#save] will return +false+.
+  # If {DuckRecord::Base#save!}[rdoc-ref:Persistence#save!] is called it will raise an DuckRecord::RecordInvalid exception.
+  # Nothing will be appended to the errors object.
+  #
+  # == Canceling callbacks
+  #
+  # If a <tt>before_*</tt> callback throws +:abort+, all the later callbacks and
+  # the associated action are cancelled.
+  # Callbacks are generally run in the order they are defined, with the exception of callbacks defined as
+  # methods on the model, which are called last.
+  #
+  # == Ordering callbacks
+  #
+  # Sometimes the code needs that the callbacks execute in a specific order. For example, a +before_destroy+
+  # callback (+log_children+ in this case) should be executed before the children get destroyed by the
+  # <tt>dependent: :destroy</tt> option.
+  #
+  # Let's look at the code below:
+  #
+  #   class Topic < DuckRecord::Base
+  #     has_many :children, dependent: :destroy
+  #
+  #     before_destroy :log_children
+  #
+  #     private
+  #       def log_children
+  #         # Child processing
+  #       end
+  #   end
+  #
+  # In this case, the problem is that when the +before_destroy+ callback is executed, the children are not available
+  # because the {DuckRecord::Base#destroy}[rdoc-ref:Persistence#destroy] callback gets executed first.
+  # You can use the +prepend+ option on the +before_destroy+ callback to avoid this.
+  #
+  #   class Topic < DuckRecord::Base
+  #     has_many :children, dependent: :destroy
+  #
+  #     before_destroy :log_children, prepend: true
+  #
+  #     private
+  #       def log_children
+  #         # Child processing
+  #       end
+  #   end
+  #
+  # This way, the +before_destroy+ gets executed before the <tt>dependent: :destroy</tt> is called, and the data is still available.
+  #
+  # Also, there are cases when you want several callbacks of the same type to
+  # be executed in order.
+  #
+  # For example:
+  #
+  #   class Topic
+  #     has_many :children
+  #
+  #     after_save :log_children
+  #     after_save :do_something_else
+  #
+  #     private
+  #
+  #     def log_chidren
+  #       # Child processing
+  #     end
+  #
+  #     def do_something_else
+  #       # Something else
+  #     end
+  #   end
+  #
+  # In this case the +log_children+ gets executed before +do_something_else+.
+  # The same applies to all non-transactional callbacks.
+  #
+  # In case there are multiple transactional callbacks as seen below, the order
+  # is reversed.
+  #
+  # For example:
+  #
+  #   class Topic
+  #     has_many :children
+  #
+  #     after_commit :log_children
+  #     after_commit :do_something_else
+  #
+  #     private
+  #
+  #     def log_chidren
+  #       # Child processing
+  #     end
+  #
+  #     def do_something_else
+  #       # Something else
+  #     end
+  #   end
+  #
+  # In this case the +do_something_else+ gets executed before +log_children+.
+  #
+  # == \Transactions
+  #
+  # The entire callback chain of a {#save}[rdoc-ref:Persistence#save], {#save!}[rdoc-ref:Persistence#save!],
+  # or {#destroy}[rdoc-ref:Persistence#destroy] call runs within a transaction. That includes <tt>after_*</tt> hooks.
+  # If everything goes fine a COMMIT is executed once the chain has been completed.
+  #
+  # If a <tt>before_*</tt> callback cancels the action a ROLLBACK is issued. You
+  # can also trigger a ROLLBACK raising an exception in any of the callbacks,
+  # including <tt>after_*</tt> hooks. Note, however, that in that case the client
+  # needs to be aware of it because an ordinary {#save}[rdoc-ref:Persistence#save] will raise such exception
+  # instead of quietly returning +false+.
+  #
+  # == Debugging callbacks
+  #
+  # The callback chain is accessible via the <tt>_*_callbacks</tt> method on an object. Active Model \Callbacks support
+  # <tt>:before</tt>, <tt>:after</tt> and <tt>:around</tt> as values for the <tt>kind</tt> property. The <tt>kind</tt> property
+  # defines what part of the chain the callback runs in.
+  #
+  # To find all callbacks in the before_save callback chain:
+  #
+  #   Topic._save_callbacks.select { |cb| cb.kind.eql?(:before) }
+  #
+  # Returns an array of callback objects that form the before_save chain.
+  #
+  # To further check if the before_save chain contains a proc defined as <tt>rest_when_dead</tt> use the <tt>filter</tt> property of the callback object:
+  #
+  #   Topic._save_callbacks.select { |cb| cb.kind.eql?(:before) }.collect(&:filter).include?(:rest_when_dead)
+  #
+  # Returns true or false depending on whether the proc is contained in the before_save callback chain on a Topic model.
+  #
+  module Callbacks
+    extend ActiveSupport::Concern
+
+    CALLBACKS = [
+      :after_initialize, :before_validation, :after_validation
+    ]
+
+    module ClassMethods # :nodoc:
+      include ActiveModel::Callbacks
+    end
+
+    included do
+      include ActiveModel::Validations::Callbacks
+
+      define_model_callbacks :initialize, :only => :after
+    end
+  end
+end