Thanks for your response! The reason it fails is that the method used when updating an entity in this project is:
1. Load entity 2. Modify entity 3. Validate entity. 4. If validation succeeds, Session.Save it, if not don't do anything. In addition, NHibernate Validator's event listeners are also active, although that's mostly due to us being cowards. I wouldn't mind removing that part. I know, it's an NHibernate antipattern, but fore database centric developers it makes a lot of sense. What happens now is that Fabio's cool listeners sets all loaded entities to ReadOnly and then sets them back to Loaded when Save is called. However, since a regular flush now will cascade also ReadOnly entities, all cascaded instances will go through the SaveUpdate event, and will be set to Loaded and may be persisted, even if the validation failed. I guess maybe what confuses me is why the SaveUpdate listener is called, when Save was never called from user code. /G 2011/5/20 Julian Maughan <[email protected]> > Just read Fabio's blog that you referred to. Its an interesting usage of > NHibernate that I haven't seen before. > > 'Read-only entities' is a feature ported faithfully from Hibernate. The > Hibernate documentation describes (in detail) the way read-only entities > behave with respect to associations (see > http://docs.jboss.org/hibernate/core/3.6/reference/en-US/html/readonly.html). > If you read this it should clarify *why* the cascade is necessary...but > basically it is. > > I'm not familiar with NHibernate Validator, but can you explain why it is > broken by the change? Presumably your entities' children are being validated > when you don't want them to be? Do your association mappings have cascading > enabled explicitly, e.g. cascade="all"? Have you tried cascade="none", and > then doing the cascade in the PreUpdateEventListener (like Fabio does in his > blog post)? >
