I did a little work on the composite_primary_keys gem last night, and I wrote
this:
module ActiveRecord
class Base
def can_change_primary_key_values?
false
end
end
end
module ActiveModel
module Dirty
def can_change_primary_key_values?
true
end
end
end
My original intention was 1) allow overriding of the ability to change
composite-primary-key values on a per-model basis, and 2) verify the inclusion
of the Dirty module (because of the requirement to know the original values).
I realized this morning that my second intention is unecessary since Dirty is
always included into an ActiveRecord model; however, I then considered
"future-proofing".
This brings me to my question: is there any future-proofing value to this (or
does anyone see this as a necessary requirement)? Specifically, with the
modularization of Rails, would it be possible (or is there any consideration)
to allow the removal of modules like Dirty from being a requirement of an
ActiveRecord model?
--
******************************************
* Travis D. Warlick, Jr.
* Software Engineer
* Zerista, Inc. & Operis Systems, LLC
******************************************
--
You received this message because you are subscribed to the Google Groups "Ruby
on Rails: Talk" group.
To post to this group, send email to rubyonrails-talk@googlegroups.com.
To unsubscribe from this group, send email to
rubyonrails-talk+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en.
