dirty_attributes incorrect in certain circumstances
Reported by Gary Yngve | July 8th, 2010 @ 05:39 PM | in 1.0.2
Normally, if you assign an attribute its own value, the
attribute is not considered dirty.
However, it is incorrectly considered dirty if the following are
true:
- there is another legitimately dirty attribute - this dirty
attribute is in the "correct" order, probably previous
alphabetically
Comments and changes to this ticket
-
Gary Yngve July 8th, 2010 @ 06:11 PM
the "correct" order is that the legit dirty attribute was assigned first -- order of the properties or property names seems irrelevant
uploaded a better repro script
-
Martin Gamsjaeger (snusnu) July 10th, 2010 @ 11:09 AM
- State changed from “new” to “confirmed”
-
Dan Kubb (dkubb) July 28th, 2010 @ 12:24 AM
- Assigned user set to “Dan Kubb (dkubb)”
- State changed from “confirmed” to “accepted”
- Milestone set to “1.0.2”
- Milestone order changed from “196228” to “0”
I think I know what is causing this. Should have a failing spec and a fix in the next hour or so.
-
Dan Kubb (dkubb) July 28th, 2010 @ 12:48 AM
- State changed from “accepted” to “resolved”
(from [75c67e6160e153ce47ce92b15fd06e8c431a375a]) Only track changed values when persisted state is Dirty
[#1355 state:resolved] http://github.com/datamapper/dm-core/commit/75c67e6160e153ce47ce92b...
Please Sign in or create a free account to add a new ticket.
With your very own profile, you can contribute to projects, track your activity, watch tickets, receive and update tickets through your email and much more.
Create new ticket
Create your profile
Help contribute to this project by taking a few moments to create your personal profile. Create your profile »
People watching this ticket
Dan Kubb (dkubb)
Gary Yngve
Martin Gamsjaeger (snusnu)
Attachments
Tags
Referenced by
-
1355
dirty_attributes incorrect in certain circumstances
[#1355 state:resolved]
http://github.com/datamapper/dm-c...