On Sep 27, 2011, at 9:34 AM, Emmanuel Gomez wrote:

> On Sep 26, 2011, at 6:18 PM, Chris Corbyn wrote:
> 
>> Yeah, this is one of the downsides, I think.  In general, you probably don't 
>> want to stack up too many changes in one go before saving, but it does feel 
>> like there needs to be a way to either get all errors from all related 
>> objects in a single list, or at least ask which objects contain errors.  
>> It's probably not too hard to patch this in, just traversing the 
>> associations graph and checking their #errors.
> 
> There is a gem called dm-validations-ext 
> (https://github.com/solnic/dm-validations-ext) which collects errors from 
> loaded parents and children and accumulates them in the receiver's error 
> collection. It is meant to be used in conjunction with dm-validations. This 
> goes some way to easing the pain of dealing with an object graph failing to 
> save.

The downside is that it only supports 1-level deep associations. So it will 
tell you about errors of the parents children but it won't tell you about the 
errors of children of those children. I hope refactored dm-validations deals 
with this better.

> A future release of dm-validations will incorporate this behavior in the base 
> library. You can see a prerelease version of this code in my fork 
> (https://github.com/emmanuel/dm-validations in the 'feature/reorganize' 
> branch). Due to a vacation and laziness, I did not get the dm-validations 
> update prepared in time for the 1.2.0 release, but it should be ready for a 
> 1.3.0, hopefully to follow soon after 1.2.0.

Right, stop being so lazy and go refactor at least 10 other plugins. 2 is not 
enough, this is hard work man, hard work ;)

Anyhow, the plan for 1.3.0 is to have the finalized property API ready *and* 
your refactored (rewritten?) dm-validations merged in for the release. I hope 
we will make it :)

> But there is another issue which can block saving of a resource and is 
> completely outside of validations: Property#valid?. This method is called 
> from DataMapper::Resource::PersistenceState::Dirty#commit 
> (https://github.com/datamapper/dm-core/blob/master/lib/dm-core/resource/persistence_state/dirty.rb#L21)
>  in order to test that resources contain valid values for their Properties 
> before attempting to save to the datastore 
> (https://github.com/datamapper/dm-core/blob/master/lib/dm-core/resource/persistence_state/dirty.rb#L86-91).
>  
> 
> A false return value from Property#valid? can cause a silent save failure (no 
> exception, no validation error). I don't to tell anyone who has debugged one 
> of these how painful this can be, especially if you are not already 
> intimately familiar with DataMapper.
> 
> I'm not sure what the best fix for this might be. I tend to favor removing 
> the Property#valid? check entirely and just letting things blow up if an 
> invalid value is present. That is my personal opinion (and not a deeply 
> considered one, at that), and I would want to discuss it widely before making 
> such a change.

This *will* be fixed in 1.3.0. I already merged in finalized work on the 
property api where dump_class / load_class settings are used to properly 
validate value types. I think we do need this validation, the only thing we 
need to improve is to add exceptions for the case where #dump doesn't return 
the value in the expected type (cause that's what Property#valid? checks). Any 
other additional checks should be removed since those are performed by 
dm-validations. I believe my recent refactor fixes most of the problems but we 
still need to raise an exception to avoid silent failures.

>> Jump on the IRC channel (irc.feenode.net/#datamapper) and ask, you may get 
>> some better responses.
> 
> That's always a good plan. You'll frequently find one or more members of the 
> core team online, and if nobody is around in a given moment, leave a message 
> and someone will get back to you.

Totally

Cheers!

# solnic

-- 
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.

Reply via email to