activerecord 1.0.0 → 3.0.0

data/lib/active_record/timestamp.rb

@@ -0,0 +1,88 @@
+module ActiveRecord
+  # = Active Record Timestamp
+  #
+  # Active Record automatically timestamps create and update operations if the
+  # table has fields named <tt>created_at/created_on</tt> or
+  # <tt>updated_at/updated_on</tt>.
+  #
+  # Timestamping can be turned off by setting:
+  #
+  #   <tt>ActiveRecord::Base.record_timestamps = false</tt>
+  #
+  # Timestamps are in the local timezone by default but you can use UTC by setting:
+  #
+  #   <tt>ActiveRecord::Base.default_timezone = :utc</tt>
+  #
+  # == Time Zone aware attributes
+  #
+  # By default, ActiveRecord::Base keeps all the datetime columns time zone aware by executing following code.
+  #
+  #   ActiveRecord::Base.time_zone_aware_attributes = true
+  #
+  # This feature can easily be turned off by assigning value <tt>false</tt> .
+  #
+  # If your attributes are time zone aware and you desire to skip time zone conversion for certain
+  # attributes then you can do following:
+  #
+  #   Topic.skip_time_zone_conversion_for_attributes = [:written_on]
+  module Timestamp
+    extend ActiveSupport::Concern
+
+    included do
+      class_inheritable_accessor :record_timestamps, :instance_writer => false
+      self.record_timestamps = true
+    end
+
+  private
+
+    def create #:nodoc:
+      if record_timestamps
+        current_time = current_time_from_proper_timezone
+
+        all_timestamp_attributes.each do |column|
+          write_attribute(column.to_s, current_time) if respond_to?(column) && self.send(column).nil?
+        end
+      end
+
+      super
+    end
+
+    def update(*args) #:nodoc:
+      if should_record_timestamps?
+        current_time = current_time_from_proper_timezone
+
+        timestamp_attributes_for_update_in_model.each do |column|
+          column = column.to_s
+          next if attribute_changed?(column)
+          write_attribute(column, current_time)
+        end
+      end
+      super
+    end
+
+    def should_record_timestamps?
+      record_timestamps && (!partial_updates? || changed?)
+    end
+
+    def timestamp_attributes_for_update_in_model
+      timestamp_attributes_for_update.select { |c| respond_to?(c) }
+    end
+
+    def timestamp_attributes_for_update #:nodoc:
+      [:updated_at, :updated_on]
+    end
+
+    def timestamp_attributes_for_create #:nodoc:
+      [:created_at, :created_on]
+    end
+
+    def all_timestamp_attributes #:nodoc:
+      timestamp_attributes_for_create + timestamp_attributes_for_update
+    end
+
+    def current_time_from_proper_timezone #:nodoc:
+      self.class.default_timezone == :utc ? Time.now.utc : Time.now
+    end
+  end
+end
+

data/lib/active_record/transactions.rb

@@ -1,102 +1,356 @@
-require 'active_record/vendor/simple.rb'
 require 'thread'
 
 module ActiveRecord
-  module Transactions # :nodoc:
-    TRANSACTION_MUTEX = Mutex.new
+  # See ActiveRecord::Transactions::ClassMethods for documentation.
+  module Transactions
+    extend ActiveSupport::Concern
 
-    def self.append_features(base)
-      super
-      base.extend(ClassMethods)
-
-      base.class_eval do
-        alias_method :destroy_without_transactions, :destroy
-        alias_method :destroy, :destroy_with_transactions
-
-        alias_method :save_without_transactions, :save
-        alias_method :save, :save_with_transactions
-      end
+    class TransactionError < ActiveRecordError # :nodoc:
     end
 
-    # Transactions are protective blocks where SQL statements are only permanent if they can all succed as one atomic action. 
-    # The classic example is a transfer between two accounts where you can only have a deposit if the withdrawal succedded and
-    # vice versa. Transaction enforce the integrity of the database and guards the data against program errors or database break-downs.
-    # So basically you should use transaction blocks whenever you have a number of statements that must be executed together or
-    # not at all. Example:
+    included do
+      define_callbacks :commit, :rollback, :terminator => "result == false", :scope => [:kind, :name]
+    end
+    # = Active Record Transactions
     #
-    #   Account.transaction do
+    # Transactions are protective blocks where SQL statements are only permanent
+    # if they can all succeed as one atomic action. The classic example is a
+    # transfer between two accounts where you can only have a deposit if the
+    # withdrawal succeeded and vice versa. Transactions enforce the integrity of
+    # the database and guard the data against program errors or database
+    # break-downs. So basically you should use transaction blocks whenever you
+    # have a number of statements that must be executed together or not at all.
+    #
+    # For example:
+    #
+    #   ActiveRecord::Base.transaction do
     #     david.withdrawal(100)
     #     mary.deposit(100)
     #   end
     #
-    # This example will only take money from David and give to Mary if neither +withdrawal+ nor +deposit+ raises an exception.
-    # Exceptions will force a ROLLBACK that returns the database to the state before the transaction was begun. Be aware, though,
-    # that the objects by default will _not_ have their instance data returned to their pre-transactional state.
+    # This example will only take money from David and give it to Mary if neither
+    # +withdrawal+ nor +deposit+ raise an exception. Exceptions will force a
+    # ROLLBACK that returns the database to the state before the transaction
+    # began. Be aware, though, that the objects will _not_ have their instance
+    # data returned to their pre-transactional state.
     #
-    # == Save and destroy are automatically wrapped in a transaction
+    # == Different Active Record classes in a single transaction
     #
-    # Both Base#save and Base#destroy come wrapped in a transaction that ensures that whatever you do in validations or callbacks
-    # will happen under the protected cover of a transaction. So you can use validations to check for values that the transaction
-    # depend on or you can raise exceptions in the callbacks to rollback.
+    # Though the transaction class method is called on some Active Record class,
+    # the objects within the transaction block need not all be instances of
+    # that class. This is because transactions are per-database connection, not
+    # per-model.
     #
-    # == Object-level transactions
+    # In this example a +balance+ record is transactionally saved even
+    # though +transaction+ is called on the +Account+ class:
     #
-    # You can enable object-level transactions for Active Record objects, though. You do this by naming the each of the Active Records
-    # that you want to enable object-level transactions for, like this:
+    #   Account.transaction do
+    #     balance.save!
+    #     account.save!
+    #   end
     #
-    #   Account.transaction(david, mary) do
-    #     david.withdrawal(100)
-    #     mary.deposit(100)
+    # The +transaction+ method is also available as a model instance method.
+    # For example, you can also do this:
+    #
+    #   balance.transaction do
+    #     balance.save!
+    #     account.save!
+    #   end
+    #
+    # == Transactions are not distributed across database connections
+    #
+    # A transaction acts on a single database connection. If you have
+    # multiple class-specific databases, the transaction will not protect
+    # interaction among them. One workaround is to begin a transaction
+    # on each class whose models you alter:
+    #
+    #   Student.transaction do
+    #     Course.transaction do
+    #       course.enroll(student)
+    #       student.units += course.units
+    #     end
     #   end
     #
-    # If the transaction fails, David and Mary will be returned to their pre-transactional state. No money will have changed hands in
-    # neither object nor database.
-    #
-    # == Exception handling
-    #
-    # Also have in mind that exceptions thrown within a transaction block will be propagated (after triggering the ROLLBACK), so you
-    # should be ready to catch those in your application code.
-    #
-    # Tribute: Object-level transactions are implemented by Transaction::Simple by Austin Ziegler.
-    module ClassMethods      
-      def transaction(*objects, &block)
-        TRANSACTION_MUTEX.lock
-
-        begin
-          objects.each { |o| o.extend(Transaction::Simple) }
-          objects.each { |o| o.start_transaction }
-          connection.begin_db_transaction
-
-          block.call
-  
-          connection.commit_db_transaction
-          objects.each { |o| o.commit_transaction }
-        rescue Exception => exception
-          connection.rollback_db_transaction
-          objects.each { |o| o.abort_transaction }
-          raise exception
-        ensure
-          TRANSACTION_MUTEX.unlock
+    # This is a poor solution, but fully distributed transactions are beyond
+    # the scope of Active Record.
+    #
+    # == +save+ and +destroy+ are automatically wrapped in a transaction
+    #
+    # Both +save+ and +destroy+ come wrapped in a transaction that ensures
+    # that whatever you do in validations or callbacks will happen under its
+    # protected cover. So you can use validations to check for values that
+    # the transaction depends on or you can raise exceptions in the callbacks
+    # to rollback, including <tt>after_*</tt> callbacks.
+    #
+    # As a consequence changes to the database are not seen outside your connection
+    # until the operation is complete. For example, if you try to update the index
+    # of a search engine in +after_save+ the indexer won't see the updated record.
+    # The +after_commit+ callback is the only one that is triggered once the update
+    # is committed. See below.
+    #
+    # == Exception handling and rolling back
+    #
+    # Also have in mind that exceptions thrown within a transaction block will
+    # be propagated (after triggering the ROLLBACK), so you should be ready to
+    # catch those in your application code.
+    #
+    # One exception is the <tt>ActiveRecord::Rollback</tt> exception, which will trigger
+    # a ROLLBACK when raised, but not be re-raised by the transaction block.
+    #
+    # *Warning*: one should not catch <tt>ActiveRecord::StatementInvalid</tt> exceptions
+    # inside a transaction block. <tt>ActiveRecord::StatementInvalid</tt> exceptions indicate that an
+    # error occurred at the database level, for example when a unique constraint
+    # is violated. On some database systems, such as PostgreSQL, database errors
+    # inside a transaction cause the entire transaction to become unusable
+    # until it's restarted from the beginning. Here is an example which
+    # demonstrates the problem:
+    #
+    #   # Suppose that we have a Number model with a unique column called 'i'.
+    #   Number.transaction do
+    #     Number.create(:i => 0)
+    #     begin
+    #       # This will raise a unique constraint error...
+    #       Number.create(:i => 0)
+    #     rescue ActiveRecord::StatementInvalid
+    #       # ...which we ignore.
+    #     end
+    #
+    #     # On PostgreSQL, the transaction is now unusable. The following
+    #     # statement will cause a PostgreSQL error, even though the unique
+    #     # constraint is no longer violated:
+    #     Number.create(:i => 1)
+    #     # => "PGError: ERROR:  current transaction is aborted, commands
+    #     #     ignored until end of transaction block"
+    #   end
+    #
+    # One should restart the entire transaction if an
+    # <tt>ActiveRecord::StatementInvalid</tt> occurred.
+    #
+    # == Nested transactions
+    #
+    # +transaction+ calls can be nested. By default, this makes all database
+    # statements in the nested transaction block become part of the parent
+    # transaction. For example:
+    #
+    #   User.transaction do
+    #     User.create(:username => 'Kotori')
+    #     User.transaction do
+    #       User.create(:username => 'Nemu')
+    #       raise ActiveRecord::Rollback
+    #     end
+    #   end
+    #
+    #   User.find(:all)  # => empty
+    #
+    # It is also possible to requires a sub-transaction by passing
+    # <tt>:requires_new => true</tt>. If anything goes wrong, the
+    # database rolls back to the beginning of the sub-transaction
+    # without rolling back the parent transaction. For example:
+    #
+    #   User.transaction do
+    #     User.create(:username => 'Kotori')
+    #     User.transaction(:requires_new => true) do
+    #       User.create(:username => 'Nemu')
+    #       raise ActiveRecord::Rollback
+    #     end
+    #   end
+    #
+    #   User.find(:all)  # => Returns only Kotori
+    #
+    # Most databases don't support true nested transactions. At the time of
+    # writing, the only database that we're aware of that supports true nested
+    # transactions, is MS-SQL. Because of this, Active Record emulates nested
+    # transactions by using savepoints. See
+    # http://dev.mysql.com/doc/refman/5.0/en/savepoints.html
+    # for more information about savepoints.
+    #
+    # === Callbacks
+    #
+    # There are two types of callbacks associated with committing and rolling back transactions:
+    # +after_commit+ and +after_rollback+.
+    #
+    # +after_commit+ callbacks are called on every record saved or destroyed within a
+    # transaction immediately after the transaction is committed. +after_rollback+ callbacks
+    # are called on every record saved or destroyed within a transaction immediately after the
+    # transaction or savepoint is rolled back.
+    #
+    # These callbacks are useful for interacting with other systems since you will be guaranteed
+    # that the callback is only executed when the database is in a permanent state. For example,
+    # +after_commit+ is a good spot to put in a hook to clearing a cache since clearing it from
+    # within a transaction could trigger the cache to be regenerated before the database is updated.
+    #
+    # === Caveats
+    #
+    # If you're on MySQL, then do not use DDL operations in nested transactions
+    # blocks that are emulated with savepoints. That is, do not execute statements
+    # like 'CREATE TABLE' inside such blocks. This is because MySQL automatically
+    # releases all savepoints upon executing a DDL operation. When +transaction+
+    # is finished and tries to release the savepoint it created earlier, a
+    # database error will occur because the savepoint has already been
+    # automatically released. The following example demonstrates the problem:
+    #
+    #   Model.connection.transaction do                           # BEGIN
+    #     Model.connection.transaction(:requires_new => true) do  # CREATE SAVEPOINT active_record_1
+    #       Model.connection.create_table(...)                    # active_record_1 now automatically released
+    #     end                                                     # RELEASE savepoint active_record_1
+    #                                                             # ^^^^ BOOM! database error!
+    #   end
+    #
+    # Note that "TRUNCATE" is also a MySQL DDL statement!
+    module ClassMethods
+      # See ActiveRecord::Transactions::ClassMethods for detailed documentation.
+      def transaction(options = {}, &block)
+        # See the ConnectionAdapters::DatabaseStatements#transaction API docs.
+        connection.transaction(options, &block)
+      end
+
+      def after_commit(*args, &block)
+        options = args.last
+        if options.is_a?(Hash) && options[:on]
+          options[:if] = Array.wrap(options[:if])
+          options[:if] << "transaction_include_action?(:#{options[:on]})"
         end
+        set_callback(:commit, :after, *args, &block)
+      end
+
+      def after_rollback(*args, &block)
+        options = args.last
+        if options.is_a?(Hash) && options[:on]
+          options[:if] = Array.wrap(options[:if])
+          options[:if] << "transaction_include_action?(:#{options[:on]})"
+        end
+        set_callback(:rollback, :after, *args, &block)
+      end
+    end
+
+    # See ActiveRecord::Transactions::ClassMethods for detailed documentation.
+    def transaction(&block)
+      self.class.transaction(&block)
+    end
+
+    def destroy #:nodoc:
+      with_transaction_returning_status { super }
+    end
+
+    def save(*) #:nodoc:
+      rollback_active_record_state! do
+        with_transaction_returning_status { super }
+      end
+    end
+
+    def save!(*) #:nodoc:
+      with_transaction_returning_status { super }
+    end
+
+    # Reset id and @new_record if the transaction rolls back.
+    def rollback_active_record_state!
+      remember_transaction_record_state
+      yield
+    rescue Exception
+      restore_transaction_record_state
+      raise
+    ensure
+      clear_transaction_record_state
+    end
+
+    # Call the after_commit callbacks
+    def committed! #:nodoc:
+      _run_commit_callbacks
+    ensure
+      clear_transaction_record_state
+    end
+
+    # Call the after rollback callbacks. The restore_state argument indicates if the record
+    # state should be rolled back to the beginning or just to the last savepoint.
+    def rolledback!(force_restore_state = false) #:nodoc:
+      _run_rollback_callbacks
+    ensure
+      restore_transaction_record_state(force_restore_state)
+    end
+
+    # Add the record to the current transaction so that the :after_rollback and :after_commit callbacks
+    # can be called.
+    def add_to_transaction
+      if self.class.connection.add_transaction_record(self)
+        remember_transaction_record_state
       end
     end
 
-    def destroy_with_transactions #:nodoc:
-      if TRANSACTION_MUTEX.locked?
-        destroy_without_transactions
-      else
-        ActiveRecord::Base.transaction { destroy_without_transactions }
+    # Executes +method+ within a transaction and captures its return value as a
+    # status flag. If the status is true the transaction is committed, otherwise
+    # a ROLLBACK is issued. In any case the status flag is returned.
+    #
+    # This method is available within the context of an ActiveRecord::Base
+    # instance.
+    def with_transaction_returning_status
+      status = nil
+      self.class.transaction do
+        add_to_transaction
+        status = yield
+        raise ActiveRecord::Rollback unless status
+      end
+      status
+    end
+
+    protected
+
+    # Save the new record state and id of a record so it can be restored later if a transaction fails.
+    def remember_transaction_record_state #:nodoc
+      @_start_transaction_state ||= {}
+      unless @_start_transaction_state.include?(:new_record)
+        @_start_transaction_state[:id] = id if has_attribute?(self.class.primary_key)
+        @_start_transaction_state[:new_record] = @new_record
+      end
+      unless @_start_transaction_state.include?(:destroyed)
+        @_start_transaction_state[:destroyed] = @destroyed
       end
+      @_start_transaction_state[:level] = (@_start_transaction_state[:level] || 0) + 1
     end
-    
-    def save_with_transactions(perform_validation = true) #:nodoc:
-      result = nil
-      if TRANSACTION_MUTEX.locked?
-        result = save_without_transactions(perform_validation)
-      else
-        ActiveRecord::Base.transaction { result = save_without_transactions(perform_validation) }
+
+    # Clear the new record state and id of a record.
+    def clear_transaction_record_state #:nodoc
+      if defined?(@_start_transaction_state)
+        @_start_transaction_state[:level] = (@_start_transaction_state[:level] || 0) - 1
+        remove_instance_variable(:@_start_transaction_state) if @_start_transaction_state[:level] < 1
+      end
+    end
+
+    # Restore the new record state and id of a record that was previously saved by a call to save_record_state.
+    def restore_transaction_record_state(force = false) #:nodoc
+      if defined?(@_start_transaction_state)
+        @_start_transaction_state[:level] = (@_start_transaction_state[:level] || 0) - 1
+        if @_start_transaction_state[:level] < 1
+          restore_state = remove_instance_variable(:@_start_transaction_state)
+          if restore_state
+            @attributes = @attributes.dup if @attributes.frozen?
+            @new_record = restore_state[:new_record]
+            @destroyed = restore_state[:destroyed]
+            if restore_state[:id]
+              self.id = restore_state[:id]
+            else
+              @attributes.delete(self.class.primary_key)
+              @attributes_cache.delete(self.class.primary_key)
+            end
+          end
+        end
+      end
+    end
+
+    # Determine if a record was created or destroyed in a transaction. State should be one of :new_record or :destroyed.
+    def transaction_record_state(state) #:nodoc
+      @_start_transaction_state[state] if defined?(@_start_transaction_state)
+    end
+
+    # Determine if a transaction included an action for :create, :update, or :destroy. Used in filtering callbacks.
+    def transaction_include_action?(action) #:nodoc
+      case action
+      when :create
+        transaction_record_state(:new_record)
+      when :destroy
+        destroyed?
+      when :update
+        !(transaction_record_state(:new_record) || destroyed?)
       end
-      return result
     end
   end
-end
+end

data/lib/active_record/validations/associated.rb

@@ -0,0 +1,48 @@
+module ActiveRecord
+  module Validations
+    class AssociatedValidator < ActiveModel::EachValidator
+      def validate_each(record, attribute, value)
+        return if (value.is_a?(Array) ? value : [value]).collect{ |r| r.nil? || r.valid? }.all?
+        record.errors.add(attribute, :invalid, options.merge(:value => value))
+      end
+    end
+
+    module ClassMethods
+      # Validates whether the associated object or objects are all valid themselves. Works with any kind of association.
+      #
+      #   class Book < ActiveRecord::Base
+      #     has_many :pages
+      #     belongs_to :library
+      #
+      #     validates_associated :pages, :library
+      #   end
+      #
+      # Warning: If, after the above definition, you then wrote:
+      #
+      #   class Page < ActiveRecord::Base
+      #     belongs_to :book
+      #
+      #     validates_associated :book
+      #   end
+      #
+      # this would specify a circular dependency and cause infinite recursion.
+      #
+      # NOTE: This validation will not fail if the association hasn't been assigned. If you want to
+      # ensure that the association is both present and guaranteed to be valid, you also need to
+      # use +validates_presence_of+.
+      #
+      # Configuration options:
+      # * <tt>:message</tt> - A custom error message (default is: "is invalid")
+      # * <tt>:on</tt> - Specifies when this validation is active (default is <tt>:save</tt>, other options <tt>:create</tt>, <tt>:update</tt>).
+      # * <tt>:if</tt> - Specifies a method, proc or string to call to determine if the validation should
+      #   occur (e.g. <tt>:if => :allow_validation</tt>, or <tt>:if => Proc.new { |user| user.signup_step > 2 }</tt>).  The
+      #   method, proc or string should return or evaluate to a true or false value.
+      # * <tt>:unless</tt> - Specifies a method, proc or string to call to determine if the validation should
+      #   not occur (e.g. <tt>:unless => :skip_validation</tt>, or <tt>:unless => Proc.new { |user| user.signup_step <= 2 }</tt>).  The
+      #   method, proc or string should return or evaluate to a true or false value.
+      def validates_associated(*attr_names)
+        validates_with AssociatedValidator, _merge_attributes(attr_names)
+      end
+    end
+  end
+end