
Destroyed objects raise errors when attempting to access unloaded attributes
Reported by dan (at angryamoeba) | June 17th, 2009 @ 10:23 AM
This issue occurs when using property types that are by default lazy-loaded. Attempting to access lazy attributes once an object has been destroyed raises a frozen object error.
Desired behaviour: Either the lazy attributes should be loaded before the object is destroyed (not always practical with large entities such as BLOB fields) or the exception should be handled by DM's exception classes so that the implementing application can handle the error.
To reproduce:
class MyModel
include DataMapper::Resource
property :id, Serial
property :foo, String
property :long, Text
end
win = MyModel.gen
win.long #=> "dsfargeg"
win.destroy
win.long #=> "dsfargeg"
fail = MyModel.gen
fail.destroy
fail.long
can't modify frozen object
/Library/Ruby/Gems/1.8/gems/dm-core-0.10.0/lib/dm-core/property.rb:630:in `instance_variable_set'
/Library/Ruby/Gems/1.8/gems/dm-core-0.10.0/lib/dm-core/property.rb:630:in `set!'
/Library/Ruby/Gems/1.8/gems/dm-core-0.10.0/lib/dm-core/property.rb:611:in `set'
/Library/Ruby/Gems/1.8/gems/dm-core-0.10.0/lib/dm-core/property.rb:541:in `get'
/Library/Ruby/Gems/1.8/gems/dm-core-0.10.0/lib/dm-core/resource.rb:174:in `attribute_get'
Comments and changes to this ticket
-
Ted Han (knowtheory) June 17th, 2009 @ 10:24 AM
- Title changed from Destroyed objects raise errors when attempting to access some attributes to Destroyed objects raise errors when attempting to access unloaded attributes
-
Ted Han (knowtheory) June 17th, 2009 @ 10:24 AM
- State changed from new to confirmed
-
Ted Han (knowtheory) June 19th, 2009 @ 01:21 PM
- Assigned user cleared.
-
Dan Kubb (dkubb) June 19th, 2009 @ 01:21 PM
- Assigned user set to Dan Kubb (dkubb)
- State changed from confirmed to accepted
- Milestone set to 0.10.0
-
Dan Kubb (dkubb) June 19th, 2009 @ 09:52 PM
There are four ways to solve this: 1) on delete, lazy load the entire object prior to freezing it or 2) throw an exception when accessing a property that hasn't been lazy loaded, 3) mark the object as frozen, and after lazy loading it, freeze it for-real 4) add something like Resource#readonly and set it on-delete.. attempts to use s mutator would cause an explosion.
Choice 1 isn't an option because it would cause undo load on systems for an edge case, and definitely violates the POLS.
I've done 3 before with LazyArray, and I now admit it was a terrible idea. Freezing is a core behavior of ruby classes, and we shouldn't be overriding them. I will be undoing this this in extlib/next shortly.
Number 4 isn't quite so bad, but I would prefer to use the built-in ruby conventions like freeze than invent our own because of this special case.
I'm leaning towards choice 2 at the moment, because it's the least magical and will require the least number fo changes internally. If you know you're going to use an object after deletion, perhaps for display, then you should explicitly load all the fields up-front by specifying :fields in the finder call.
-
Dan Kubb (dkubb) October 4th, 2009 @ 09:33 PM
- Milestone changed from 0.10.0 to 0.10.2
[project:id#20609 not-tagged:"0.10.0" milestone:id#51895 bulk edit command]
-
Dan Kubb (dkubb) February 1st, 2010 @ 04:33 PM
- Milestone changed from 0.10.2 to 1.0.0
-
-
-
Dan Kubb (dkubb) February 2nd, 2010 @ 02:47 AM
- State changed from accepted to confirmed
-
Dan Kubb (dkubb) May 23rd, 2010 @ 09:19 PM
- State changed from confirmed to resolved
- Assigned user set to Dan Kubb (dkubb)
Lazy loading an unloaded attribute on a destroyed object will now raise a DM::ImmutableError exception.
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 your profile
Help contribute to this project by taking a few moments to create your personal profile. Create your profile »