Forum: Ruby on Rails ActiveRecord handling of obj.dup vs obj.clone

Announcement (2017-05-07): is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see and for other Rails- und Ruby-related community platforms.
E502d69beec5c8337e4255838db65fd2?d=identicon&s=25 Daudi Mogaka (dsaronin)
on 2009-01-09 05:03
AR seems to be handling model object dup and cloning differently from
Ruby documented behavior.  I've checked out both ways (as an AR model
and not) and the behavior is different.  I don't see anything in the
RAILS documentation about this.  Am I missing something? is this a bug?
a feature? an interesting lifestyle?
I can easily hack around this difference/bug/feature but it should be
example 1 using AR:

class Model < ActiveRecord::Base
# etc, normal model stuff, associations
  def initialize_copy(old_obj)
    # do something

obj = Model.find(1)
obj_dup = obj.dup   # does NOT yield a new object;
                    # does invoke obj_dup.initialize_copy(obj)
# at this point obj_dup is same object as obj;
# any changes to obj_dup will change obj
# but obj_dup changes have not been saved to DB yet

obj_clone = obj.clone  # does yield a new object;
                       # does NOT invoke obj_clone.initialize_copy(obj)
# at this point obj_clone is a different object but not yet saved to DB
# which is ok and expected; NOT invoking initialize_copy is NOT ok
example 2 using pure Ruby:

class Test
   attr_reader  :name
   def initialize(str)
     @name = str
   def initialize_copy(old)
      @name += ' *** COPY ***'

a = 'john'   # is now: 'john'
b = a.dup    # is now: 'john *** COPY ***'
c = a.clone  # is now: 'john *** COPY ***'

# a, b, c are all DIFFERENT objects
# b.initialize_copy(a) was invoked per Ruby documentation #
c.initialize_copy(a) was invoked per Ruby documentation
This topic is locked and can not be replied to.