|
Hi
We have a domain class that has a 'state' property, e.g. 'live', 'draft', etc. When our users click the save button on the edit form they can change the state, however if any validation errors occur the state should not change (including on the form displaying the errors - where other user entered values would be displayed even if not persisted yet). At the moment we've got some rather hairy business logic managing the state field, so we do something roughly like: if (asset.validate()) { asset.state = params.nextState asset.save() // redirect, etc. } else { // re-render form with errors } This is repeated in a couple of places as the domain class in question is actually the root class of a whole hierarchy. I thought it might be better to model the 'nextState' as a transient property which can be bound directly from the form, then do this: def beforeUpdate = { if (owner.nextState != state) { state = owner.nextState } } This works fine so long as some other persistent property is changed, but if all the user is doing is changing the object's state (which will generally be the case) then the update never happens as 'nextState' is a transient property and thus the object is not considered dirty in the Hibernate session. Is there a way I can 'force' the dirty state of the object? It's possibly not going to result in the nicest code and we'd be better off just sticking with the current mechanism, but my curiosity has been piqued now. Cheers, Rob --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email |
|
Hi Rob,
I don't know how can you call directly the hibernate session, but once you did that you can call the update() method it will schedule a sql update against the database. session.update(asset); By default hibernate don't check if the state (not your property) of the object has changed it only do the update as you want. Regards, --- Felipe Marin Cypriano Vitória - ES On Wed, Mar 11, 2009 at 7:13 PM, Robert Fletcher <[hidden email]> wrote: Hi |
|
Rob,
I think you can increment version number - this will make the object dirty. Felipe Cypriano wrote: > Hi Rob, > > I don't know how can you call directly the hibernate session, but once > you did that you can call the update() method it will schedule a sql > update against the database. > > session.update(asset); > > By default hibernate don't check if the state (not your property) of the > object has changed it only do the update as you want. > > > Regards, > --- > Felipe Marin Cypriano > Vitória - ES > > > On Wed, Mar 11, 2009 at 7:13 PM, Robert Fletcher > <[hidden email] > <mailto:[hidden email]>> wrote: > > Hi > > We have a domain class that has a 'state' property, e.g. 'live', > 'draft', etc. When our users click the save button on the edit form > they can change the state, however if any validation errors occur the > state should not change (including on the form displaying the errors - > where other user entered values would be displayed even if not > persisted yet). At the moment we've got some rather hairy business > logic managing the state field, so we do something roughly like: > > if (asset.validate()) { > asset.state = params.nextState > asset.save() > // redirect, etc. > } else { > // re-render form with errors > } > > This is repeated in a couple of places as the domain class in question > is actually the root class of a whole hierarchy. I thought it might be > better to model the 'nextState' as a transient property which can be > bound directly from the form, then do this: > > def beforeUpdate = { > if (owner.nextState != state) { > state = owner.nextState > } > } > > This works fine so long as some other persistent property is changed, > but if all the user is doing is changing the object's state (which > will generally be the case) then the update never happens as > 'nextState' is a transient property and thus the object is not > considered dirty in the Hibernate session. > > Is there a way I can 'force' the dirty state of the object? It's > possibly not going to result in the nicest code and we'd be better off > just sticking with the current mechanism, but my curiosity has been > piqued now. > > Cheers, > Rob > > --------------------------------------------------------------------- > To unsubscribe from this list, please visit: > > http://xircles.codehaus.org/manage_email > > > -- Fernando "Takai" http://flickr.com/photos/supeertakai http://fernandotakai.jaiku.com Get Ubiquity: https://ubiquity.mozilla.com --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email |
| Powered by Nabble | Edit this page |
