Jérôme Lafréchoux

@Bernie, I'm not sure we can even try to support this. The issue is the same with embedded documents and lists, isn't it? Only the first document level generates `'$set'`...

Sorry about the delay. I agree with this change. I pushed a branch where I tried this on `Reference` field (to fix #349 @richiq) and I'm happy with it. https://github.com/Scille/umongo/tree/reference_cls...

You could override `__init__` to do the hashing there, I suppose. My preference for this use case is to add a dedicated setter method for password and call it after...

Indeed the same schema load happens when loading from base and at init. You could use a post_load hook (see marchmallow docs) but it would be executed in both cases....

Unless I'm missing something, this is a really blocking issue, as this allows to set invalid data that will not be checked even at commit time. I could modify `List`...

I'm glad to hear this should work. Indeed, I realized afterwards that even list elements mutations are catchable since these are not just objects but umongo fields (DictField being an...

~Related: `del my_document.my_list[i]` doesn't mark `my_list` field as modified.~ (Fixed in #195)

This also affects `DictField.update` and such.

In fact, reading @touilleMan's comment above, I'm realizing that validators other than field validators, such as schema-level validators are only executed when loading data on object instantiation (`__init__` -> schema...

I guess it is a balance. If a workflow implies many affectations (setattr) before a single commit, the perf penalty from the test could be important. I'm thinking about huge...