loadable detached models and versioning
Hi all. I'm new to wicket. I was reading in the Wicket In Action book on LoadableDetachedModels...particularly how when the model is detached, just the id of the actual database persistent object is stored. Then, in the load method, you retrieve the persistent object from the database. That all makes sense. However, I then read one use case for this, at http://stronglytypedblog.blogspot.com/2009/03/wicket-patterns-and-pitfalls-1.html. The idea is that you retrieve the object from the database to present in a form, and then when a person submits the form, you retrieve the object from the database again, apply any needed changes, and then persist the object. Isn't there a problem here related to versioning of objects? Specifically, the first time I retrieve an object, it could be at version 1. The next time I retrieve the object, to apply the values from the form, I could be retrieving version 4. I would then apply the changes from the form, and hibernate would happily persist the object, because version 4 is the most current. On the other hand, if I kept the version 1 model in the session, and then applied the form values to it, and then tried to persist it, and in the meantime other changes had caused the version in the database to increase to 4, hibernate would (properly) throw an error because I am not persisting a change to the most current version. David
Re: loadable detached models and versioning
On Wed, May 12, 2010 at 10:52 AM, David Sheth da...@dsheth.com wrote: Hi all. I'm new to wicket. I was reading in the Wicket In Action book on LoadableDetachedModels...particularly how when the model is detached, just the id of the actual database persistent object is stored. Then, in the load method, you retrieve the persistent object from the database. That all makes sense. However, I then read one use case for this, at http://stronglytypedblog.blogspot.com/2009/03/wicket-patterns-and-pitfalls-1.html. The idea is that you retrieve the object from the database to present in a form, and then when a person submits the form, you retrieve the object from the database again, apply any needed changes, and then persist the object. Isn't there a problem here related to versioning of objects? Specifically, the first time I retrieve an object, it could be at version 1. The next time I retrieve the object, to apply the values from the form, I could be retrieving version 4. I would then apply the changes from the form, and hibernate would happily persist the object, because version 4 is the most current. Yes, Hibernate's automatic optimistic locking fails in this scenario. You can add your own validator onto the form (with a hidden field for the version) if you want. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: loadable detached models and versioning
Hello, Another option would be to make your detachable model aware of the version aswell as the id which will allow you to catch this case. Process: Cache the version aswell as the object id. Then either do a query to make sure the cached version is still valid or wait until after the object is materialized and then check the version like: Object dbBackedObject = loadFromDataBase (objectId); if (!dbBackedObject.getVersion().equals (cachedVersion)) throw new RuntimeException(stale version excetption); I'm not sure if you can catch the exception within the form processing or if it will bubble up to the request cycle exception handling logic (where you can redirect to another page). Regards, Mike Hi all. I'm new to wicket. I was reading in the Wicket In Action book on LoadableDetachedModels...particularly how when the model is detached, just the id of the actual database persistent object is stored. Then, in the load method, you retrieve the persistent object from the database. That all makes sense. However, I then read one use case for this, at http://stronglytypedblog.blogspot.com/2009/03/wicket-patterns-and-pitfalls-1.html. The idea is that you retrieve the object from the database to present in a form, and then when a person submits the form, you retrieve the object from the database again, apply any needed changes, and then persist the object. Isn't there a problem here related to versioning of objects? Specifically, the first time I retrieve an object, it could be at version 1. The next time I retrieve the object, to apply the values from the form, I could be retrieving version 4. I would then apply the changes from the form, and hibernate would happily persist the object, because version 4 is the most current. Yes, Hibernate's automatic optimistic locking fails in this scenario. You can add your own validator onto the form (with a hidden field for the version) if you want. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
