Hey Aaron, This is totally open to suggestions, this is actually something i discussed w/ dkubb last week, although my problem was only loosely related:
http://irclogger.com/datamapper/2010-04-15#1271312167 02:16 <@dkubb> knowtheory: one of the things I'd like to do is change how retrieved data is mapped to the resources 02:16 <@dkubb> knowtheory: for example, right now we map each "Hash" to the resource immediately 02:16 < knowtheory> o? 02:16 <@dkubb> knowtheory: what I would like to do is store this Hash somewhere, but not assign it. when the attribute is asked for, I'd take the value, dup it, and assign that to the resource 02:17 < knowtheory> yep! 02:17 <@dkubb> knowtheory: what this would do is two things, fix the problem you noticed, but more importantly provide a simple way to do dirtyness checking 02:17 <@dkubb> knowtheory: actually this is something I've wanted to do for a few months now, your problem is just more evidence that it's the correct path 02:18 <@dkubb> knowtheory: a nice side effect of this is that since we're deferring assignment of the values, retrieving objects from the datastore should actually increase in speed 02:18 < knowtheory> Yep :) 02:19 < knowtheory> So, where should the attrs be stored? :D 02:19 <@dkubb> knowtheory: plus there's a good chance that you won't use all of the values anyway, so by deferring, we save time if we never have to do the work 02:19 <@dkubb> I dunno :P 02:20 <@dkubb> when using the ActiveRecord pattern it's ok to store the objects somewhere inside the object as long as you make sure there's a low chance of collision in the method name 02:20 <@dkubb> but I'm more worried about how we'd do it when mapping normal ruby objects in the future 02:21 < knowtheory> yeah. 02:21 <@dkubb> I think in those cases, since you'd probably fetch using some kind of Session/UoW object, it would store the mapping 02:21 < knowtheory> dkubb: neat. yeah i was going to ask whether there was some sort of global registry of that info... 02:22 < knowtheory> which doesn't seem quite natural to me in terms of what data lives where... 02:22 < knowtheory> but the identity map is basically the same sort of object 02:22 <@dkubb> even with the DataMapper pattern, I think we have to wrap the accessor/mutators in normal objects anyway, so those could hold a reference to the UoW that was used to fetch the object On Tue, Apr 20, 2010 at 9:28 PM, Aaron Pfeifer <[email protected]>wrote: > Hey guys, > > One of the things I've noticed with DataMapper's dirty attribute > tracking is that there doesn't seem to be an elegant way to mark > attributes as dirty when they're modified in-place. For example, you > might have the following: > > p = Person.get(1) > p.name << "foo" > p.dirty? # => false > > Ideally, there would be a way to mark an attribute as dirty (like > ActiveRecord's {attribute}_will_change!). Right now, the way to > manually do this is pretty brittle from release to release. > > Is this a feature that's been considered before or is it open to > consideration? For what it's worth, the reason I'm looking for this > functionality is that I need it to properly save DataMapper records in > state_machine when a loopback occurs. I'd like to have a more stable > implementation for that scenario (rather than messing with things in > DataMapper that are likely intended to be for internal usage only). > > Thanks. > > -- > You received this message because you are subscribed to the Google Groups > "DataMapper" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]<datamapper%[email protected]> > . > For more options, visit this group at > http://groups.google.com/group/datamapper?hl=en. > > -- You received this message because you are subscribed to the Google Groups "DataMapper" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/datamapper?hl=en.
