For persistence, I use the ActiveObjects ORM library, originally developed by Daniel Spiewak and now actively maintained by Atlassian. In AO, database entities are described by java interfaces. For your use case (transient objects that may or may not be persisted), I use a dynamic proxy whose implementation can be serialized. When setters are called on the entity, the proxy stores the (unsaved) data in a HashMap. An actual database record is only created on an explicit call to entity.save().
By implementing it this way, panels that manipulate database records can operate on either new (transient) records or records that already exist. If the user cancels without saving, there is no detritus in the database to clean up. If anyone out there is interested in using AO with Wicket, I’d be happy to share my code & experience. I like the AO programming model, and its support for automatic schema migration means that you can change table definitions by adding/removing setters and getters in the entity interfaces; AO can infer the SQL to migrate tables to the new schema. For a quick (but somewhat outdated) introduction to AO, see: https://activeobjects.java.net/0.8.2/ActiveObjects.pdf <https://activeobjects.java.net/0.8.2/ActiveObjects.pdf> The repository can be found here: https://bitbucket.org/activeobjects <https://bitbucket.org/activeobjects> It’s an obscure framework, but I find it a pleasure to use, and it plays reasonably well with Wicket. -Don > On Jun 19, 2015, at 3:43 AM, Urbani, Edmund <edmund.urb...@lilandit.com> > wrote: > > On 06/19/2015 01:59 AM, wix wrote: >> Urbani, Edmund wrote >>> I don't think I am the only one running into these kinds of issues, so I'd >>> like >>> to hear which patterns other developers apply or what they consider best >>> practices. >> Would like to hear the same. I've attempted to work through this in the >> most Wicket-way I know how. >> >> The approach so far is a kind of LoadableDetachableModel that tries to be >> smart about the persistent state of the underlying entity/object. A >> persistence provider (entitymanager or such) would be injected into the >> model or requested by the model, and a flag or flags used to track the state >> of the underlying entity - is the entity currently managed? is the entity to >> be retained (that is, not automatically detached)? is the entity currently >> attached? >> >> So at the start of a wizard, the model is given a new entity and told that >> it is un-managed and retained. As the model is passed to the next page or to >> a previous page, the entity is serialized (not detached) and treated as >> though it doesn't belong to a persistence context. At the end of the wizard >> the model is told to persist the entity at which time it becomes managed but >> not retained (so it detaches, and would be re-attached via persistence id >> lookup when the model is next deserialized/loaded). >> >> A wizard or other set of pages working with an existing entity that was >> selected from persistence just tells the model that it is managed and >> retained. Then the model still doesn't "detach" in the sense of setting the >> underlying entity to null, but it does "detach" from the JPA context and is >> safely(?) serialized. Thereby changes made in wizard pages ride along to the >> end as in the new entity case above, and aren't merged til whatever final >> page/part logic says so. Cancelling out in the middle is simple since no >> changed would have been persisted. >> >> It works for any generic entity in my projects so far, however my use case >> right now isn't complicated by multi-entity editing; only one entity (one >> model's underlying object) is being modified by a single form submission in >> the open-session-in-view cycle. >> >> If there are other drawbacks to this approach or a better way (a more >> Wicket-way)... > Detaching from Hibernate / JPA session as you describe is another way to > handle this. Makes me worry about concurrent modifications which might be > committed in between detaching from / re-attaching to the persistence layer > though. > > Also, I have considered separating the presentation layer (Wicket) from the > managed database objects entirely and handle every interaction with the > database through a service layer which maps database objects to/from a > different set of classes tailored specifically for the UI and its various use > cases. That would be the "cleanest" approach I can think of, and also the > most expensive one to implement. > > However, currently I am trying to hook into the serialization process to > untangle my partially persistent object graph as described in this article: > http://techblog.molindo.at/2009/03/detaching-and-attaching-persistent-objects-on-serialization.html > > <http://techblog.molindo.at/2009/03/detaching-and-attaching-persistent-objects-on-serialization.html> > > This seems to be working so far (pending some thorough testing) even though > it causes some weird exceptions in unit tests > (javassist.CannotCompileException), which I have yet to fix. > > -- > Mit freundlichen Grüßen > Edmund Urbani > Liland IT Team > > Email: edmund.urb...@lilandit.com <mailto:edmund.urb...@lilandit.com> > Liland IT GmbH ...does IT better > Tel: +43 463 220111 > Fax: +43 463 220111-33 > Tel(GER): +49 221 65028588 > > Find us at Facebook http://facebook.com/Lilandit > <http://facebook.com/Lilandit> > http://green-badges.com <http://green-badges.com/> > http://iventcloud.com <http://iventcloud.com/> > http://Lilandit.com > > <http://www.lilandit.com/><Liland-130.png> <http://www.lilandit.com/> > Copyright © 2015, Liland IT GmbH > > Diese Mail enthaelt vertrauliche und/oder rechtlich geschuetzte Informationen. > Wenn Sie nicht der richtige Adressat sind oder diese Email irrtuemlich > erhalten haben, informieren Sie bitte sofort den Absender und vernichten Sie > diese Mail. Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser > Mail ist nicht gestattet. > > This email may contain confidential and/or privileged information. > If you are not the intended recipient (or have received this email in error) > please notify the sender immediately and destroy this email. Any unauthorised > copying, disclosure or distribution of the material in this email is strictly > forbidden. >
