I've been investigating some interesting behavior regarding model-driven actions and found a past thread that covers the situation from late last year: http://www.nabble.com/ModelDriven-CRUD-validation-failure-still-causes-JPA-update-td12987242.html
First I outline the problem, then a possible framework provided solution and a request for feedback before I start trying to generate a patch. In brief: Configuration: ModelDriven with validation is configured Hibernate/JPA is being used (OpenEntityManagerInView/OpenSessionInView is something of a red-herring) Sequence of Events: Model is loaded from DB Params (second params) inject parameters into the model Validation fails Input reached session.flush occurs (either from closing the session in OSIV pattern, OR from an implicit flush before an explicit query or a lazy-load query) dirty and invalid object written to the DB In the thread referenced, his solution was to preload all collections backing form elements -- thus avoiding the lazy-load queries after dirtying the object. (This is why I say a lot of the discussion in that thread about the flush in OEMIV is a red-herring. It could cause the problem, but wasn't the cause of the problem) A lot of the other workarounds suggested in the thread seem very unclean as its something that should be taken care of by the framework. To my eye, there is a fundamental flaw in Struts 2 validation (and type conversion). Under the model-driven paradigm, validation conditions need to be viewed as invariants, and either all fields should be set or none -- it should be atomic. There is also a violation of the SRP going on by making the model objects responsible for holding and redisplaying invalid values to the web form. It would seem to be a way forward exists, however. Model Driven can be tweaked as follows: The model driven interceptor would need to a) capture the raw request parameters into some storage b) skip the second params interceptor c) create a copy of the getModel object (to ensure its detached from any persistence session -- need to make sure this works for other common persistence engines) d) run params/validation on this copy e) if no validation errors, run params on the orginal (still attached to the persistence session), and proceed as normal f) if validation errors, intercept calls to the getters for values in the raw request for redisplay -- need to worry about XSS issues here There's a lot of moving pieces, and I'm sure I'm missing some even more subtle interactions. However I do think something needs to be done. I'm interesting in tackling this, and am hoping for some feedback on the above outline of required changes. Thank you for reading, Eric Nielsen --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
