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
unnecessary.
example 1 using AR:
class Model < ActiveRecord::Base
etc, normal model stuff, associations
def initialize_copy(old_obj)
# do something
end
end
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
end
def initialize_copy(old)
@name += ’ *** COPY ***’
end
end
a = Test.new ‘john’ # a.name is now: ‘john’
b = a.dup # b.name is now: ‘john *** COPY ***’
c = a.clone # c.name 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