custom properties in unsaved associations are reverted to dumped_value rather than loaded_value
Reported by Ryan | June 23rd, 2010 @ 11:16 PM | in 1.1
I have a model (e.g., Person) with a custom property (e.g., Enum or Flag) and a one-to-many relationship with another model (e.g., Post). If I instantiate a Person (without saving), then associate it with a Post, the value of the custom property is reverted to the dumped value, rather than the loaded_value, as would be correct.
I made a test case here:
http://gist.github.com/450961
It appears to be related to the default_attributes being stored by the collection (in the method DataMapper::Collection#default_attributes). Storing condition.loaded_value rather than condition.value seems to fix it.
Comments and changes to this ticket
-
Piotr Solnica (solnic) June 24th, 2010 @ 04:18 AM
- Milestone set to “1.0.2”
- State changed from “new” to “unconfirmed”
- Assigned user set to “Piotr Solnica (solnic)”
-
mark July 10th, 2010 @ 07:42 AM
- Milestone order changed from “0” to “0”
Happened for me to when I used YAML-serialized values on unsaved child association.
-
Piotr Solnica (solnic) July 11th, 2010 @ 04:23 PM
- State changed from “unconfirmed” to “confirmed”
-
Piotr Solnica (solnic) July 12th, 2010 @ 04:26 PM
- Assigned user changed from “Piotr Solnica (solnic)” to “Dan Kubb (dkubb)”
Dan, I spent some decent amount of time trying to track it down and I only found out that once you retrieve an associated object via resource.persisted_state.get method, the object's custom property values are altered (for the first time a dumped value is returned and nil for the second time!). Maybe it has something to do with lazy loading. I'm assigning the ticket to you since I won't be able to fix it.
-
Ryan July 12th, 2010 @ 04:50 PM
It appears to me that any unsaved objects are regenerated from scratch when retrieved through an association with another object -- with any already-set properties being copied over. I don't understand exactly why that is done, but in any case, the bug seems to occur when these properties are copied. Instead of copying the loaded_value, it copies the (raw) value, but assigns it as if it were a loaded value.
See line 1270 of:
http://github.com/datamapper/dm-core/blob/master/lib/dm-core/collec... -
Dan Kubb (dkubb) September 7th, 2010 @ 08:54 PM
- Milestone changed from “1.0.2” to “1.1”
-
-
Piotr Solnica (solnic) January 16th, 2011 @ 08:17 PM
(from [3426299cfe5de84f2350b0c57d45e2a6d0af378d]) Collection should use loaded values when setting up default attributes
[#1336 state:fixed] [#1411 state:fixed] https://github.com/datamapper/dm-core/commit/3426299cfe5de84f2350b0...
-
Piotr Solnica (solnic) January 16th, 2011 @ 08:22 PM
- State changed from “confirmed” to “resolved”
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)
Piotr Solnica (solnic)
Rolly
Xavier Shay
Tags
Referenced by
-
1411
Enum doesn't play nicely with validations
[#1336 state:fixed] [#1411
state:fixed]
https://github.c...
-
1336
custom properties in unsaved associations are reverted to dumped_value rather than loaded_value
[#1336 state:fixed] [#1411
state:fixed]
https://github.c...
-
1411
Enum doesn't play nicely with validations
#1336 is related