Best practice for updating JPA object without persisting changes
I'm dealing with an issue that I'm sure has been solved by many people on this list, but I'm struggling to ascertain the best way to solve it. I'm working on implementing in-place-edit functionality for some of our site content. The content is stored in a database and mapped via JPA. The edit form has the JPA entity as the backing model object. One of the features I'm implementing is the ability to preview what's been entered in the form without the updates being committed to the database (until the user explicitly clicks on the Save button). I can think of a few ways to accomplish this: 1. Rollback the transaction when not saving - This would require me to manage the transaction manually (right now, they're being managed automatically by Guice's PersistFilter). 2. Detach the object from the persistence context, merge it to save - This seems like the most elegant solution, but I can see how there could be issues (not intractable) with lazy loading. 3. Prevent the form from updating the model until save - This would break my preview panel, and seems to be contrary to how forms normally behave. 4. Copy the data into a non-managed DTO, copying it back to the JPA object on save - Would require a lot of clone/copy code. This seems like such a common problem to solve - I think my relative unfamiliarity with JPA is the main stumbling block here. How have others implemented it? Is there a best-practice pattern that my Googling didn't discover? Thanks in advance for the help. I hope that it isn't too off-topic since it is mainly JPA-related. Best, Chris
Re: Best practice for updating JPA object without persisting changes
Hi Chris, I would go for option 4. This is how I implement such cases. It has an explicit distinction between states 'previewMode' and 'commited Mode'. Looks like more coding, but actually is clear about distinction between preview and saved. And that would help the programmer that picks this code up a half year from now. My 2 cents. Best, Haiko Chris Snyder chris.sny...@biologos.org schreef: I'm dealing with an issue that I'm sure has been solved by many people on this list, but I'm struggling to ascertain the best way to solve it. I'm working on implementing in-place-edit functionality for some of our site content. The content is stored in a database and mapped via JPA. The edit form has the JPA entity as the backing model object. One of the features I'm implementing is the ability to preview what's been entered in the form without the updates being committed to the database (until the user explicitly clicks on the Save button). I can think of a few ways to accomplish this: 1. Rollback the transaction when not saving - This would require me to manage the transaction manually (right now, they're being managed automatically by Guice's PersistFilter). 2. Detach the object from the persistence context, merge it to save - This seems like the most elegant solution, but I can see how there could be issues (not intractable) with lazy loading. 3. Prevent the form from updating the model until save - This would break my preview panel, and seems to be contrary to how forms normally behave. 4. Copy the data into a non-managed DTO, copying it back to the JPA object on save - Would require a lot of clone/copy code. This seems like such a common problem to solve - I think my relative unfamiliarity with JPA is the main stumbling block here. How have others implemented it? Is there a best-practice pattern that my Googling didn't discover? Thanks in advance for the help. I hope that it isn't too off-topic since it is mainly JPA-related. Best, Chris - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Best practice for updating JPA object without persisting changes
Hi Chris, does the Guice's PersistFilter really automatically find and re-attach the backed object in the request while leaving the in-place-edit situation? I thought... as long as nothing/nobody finds and re-attach the backed object, your changes are naturally temporary and only stored on page cache. I would expect, it should already work out-of-the-box... But I did not work with Guice's PersistFilter, yet. May I miss something... kind regards Patrick Am 05.03.2014 12:47, schrieb Chris Snyder: I'm dealing with an issue that I'm sure has been solved by many people on this list, but I'm struggling to ascertain the best way to solve it. I'm working on implementing in-place-edit functionality for some of our site content. The content is stored in a database and mapped via JPA. The edit form has the JPA entity as the backing model object. One of the features I'm implementing is the ability to preview what's been entered in the form without the updates being committed to the database (until the user explicitly clicks on the Save button). I can think of a few ways to accomplish this: 1. Rollback the transaction when not saving - This would require me to manage the transaction manually (right now, they're being managed automatically by Guice's PersistFilter). 2. Detach the object from the persistence context, merge it to save - This seems like the most elegant solution, but I can see how there could be issues (not intractable) with lazy loading. 3. Prevent the form from updating the model until save - This would break my preview panel, and seems to be contrary to how forms normally behave. 4. Copy the data into a non-managed DTO, copying it back to the JPA object on save - Would require a lot of clone/copy code. This seems like such a common problem to solve - I think my relative unfamiliarity with JPA is the main stumbling block here. How have others implemented it? Is there a best-practice pattern that my Googling didn't discover? Thanks in advance for the help. I hope that it isn't too off-topic since it is mainly JPA-related. Best, Chris
Re: Best practice for updating JPA object without persisting changes
Hi Patrick, Thanks for the response. does the Guice's PersistFilter really automatically find and re-attach the backed object in the request while leaving the in-place-edit situation? Guice doesn't do anything with whether the objects are attached - I'm simply never detaching them (unless I implement option #2), so any changes made to the object are automatically persisted by the JPA engine. Guice's role here is with transactions - the PersistFilter starts a transaction at the beginning of the request, and commits it at the end. Thanks, Chris On Wed, Mar 5, 2014 at 8:29 AM, Patrick Davids patrick.dav...@nubologic.com wrote: Hi Chris, I thought... as long as nothing/nobody finds and re-attach the backed object, your changes are naturally temporary and only stored on page cache. I would expect, it should already work out-of-the-box... But I did not work with Guice's PersistFilter, yet. May I miss something... kind regards Patrick Am 05.03.2014 12:47, schrieb Chris Snyder: I'm dealing with an issue that I'm sure has been solved by many people on this list, but I'm struggling to ascertain the best way to solve it. I'm working on implementing in-place-edit functionality for some of our site content. The content is stored in a database and mapped via JPA. The edit form has the JPA entity as the backing model object. One of the features I'm implementing is the ability to preview what's been entered in the form without the updates being committed to the database (until the user explicitly clicks on the Save button). I can think of a few ways to accomplish this: 1. Rollback the transaction when not saving - This would require me to manage the transaction manually (right now, they're being managed automatically by Guice's PersistFilter). 2. Detach the object from the persistence context, merge it to save - This seems like the most elegant solution, but I can see how there could be issues (not intractable) with lazy loading. 3. Prevent the form from updating the model until save - This would break my preview panel, and seems to be contrary to how forms normally behave. 4. Copy the data into a non-managed DTO, copying it back to the JPA object on save - Would require a lot of clone/copy code. This seems like such a common problem to solve - I think my relative unfamiliarity with JPA is the main stumbling block here. How have others implemented it? Is there a best-practice pattern that my Googling didn't discover? Thanks in advance for the help. I hope that it isn't too off-topic since it is mainly JPA-related. Best, Chris
Re: Best practice for updating JPA object without persisting changes
Hi Haiko, Thanks for the response. You raise some good points - it certainly would be cleaner and easier to understand. It also could be better for my layout, given the way I've organized the code: The data layer is abstracted behind a service API, so we could plug in a different storage engine (Cassandra instead of JPA, for example) without needing to modify the other layers. The editor code currently has no knowledge of JPA, so I'd have to expose some of the business layer to implement either of my first two options. Do you use any tools to make the copying easier, or do you code it by hand? Thanks, Chris On Wed, Mar 5, 2014 at 8:07 AM, ha...@dds.nl wrote: Hi Chris, I would go for option 4. This is how I implement such cases. It has an explicit distinction between states 'previewMode' and 'commited Mode'. Looks like more coding, but actually is clear about distinction between preview and saved. And that would help the programmer that picks this code up a half year from now. My 2 cents. Best, Haiko Chris Snyder chris.sny...@biologos.org schreef: I'm dealing with an issue that I'm sure has been solved by many people on this list, but I'm struggling to ascertain the best way to solve it. I'm working on implementing in-place-edit functionality for some of our site content. The content is stored in a database and mapped via JPA. The edit form has the JPA entity as the backing model object. One of the features I'm implementing is the ability to preview what's been entered in the form without the updates being committed to the database (until the user explicitly clicks on the Save button). I can think of a few ways to accomplish this: 1. Rollback the transaction when not saving - This would require me to manage the transaction manually (right now, they're being managed automatically by Guice's PersistFilter). 2. Detach the object from the persistence context, merge it to save - This seems like the most elegant solution, but I can see how there could be issues (not intractable) with lazy loading. 3. Prevent the form from updating the model until save - This would break my preview panel, and seems to be contrary to how forms normally behave. 4. Copy the data into a non-managed DTO, copying it back to the JPA object on save - Would require a lot of clone/copy code. This seems like such a common problem to solve - I think my relative unfamiliarity with JPA is the main stumbling block here. How have others implemented it? Is there a best-practice pattern that my Googling didn't discover? Thanks in advance for the help. I hope that it isn't too off-topic since it is mainly JPA-related. Best, Chris - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Best practice for updating JPA object without persisting changes
have a look here: https://www.42lines.net/2011/12/01/simplifying-non-trivial-user-workflows-with-conversations/ -igor On Wed, Mar 5, 2014 at 3:47 AM, Chris Snyder chris.sny...@biologos.org wrote: I'm dealing with an issue that I'm sure has been solved by many people on this list, but I'm struggling to ascertain the best way to solve it. I'm working on implementing in-place-edit functionality for some of our site content. The content is stored in a database and mapped via JPA. The edit form has the JPA entity as the backing model object. One of the features I'm implementing is the ability to preview what's been entered in the form without the updates being committed to the database (until the user explicitly clicks on the Save button). I can think of a few ways to accomplish this: 1. Rollback the transaction when not saving - This would require me to manage the transaction manually (right now, they're being managed automatically by Guice's PersistFilter). 2. Detach the object from the persistence context, merge it to save - This seems like the most elegant solution, but I can see how there could be issues (not intractable) with lazy loading. 3. Prevent the form from updating the model until save - This would break my preview panel, and seems to be contrary to how forms normally behave. 4. Copy the data into a non-managed DTO, copying it back to the JPA object on save - Would require a lot of clone/copy code. This seems like such a common problem to solve - I think my relative unfamiliarity with JPA is the main stumbling block here. How have others implemented it? Is there a best-practice pattern that my Googling didn't discover? Thanks in advance for the help. I hope that it isn't too off-topic since it is mainly JPA-related. Best, Chris - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Best practice for updating JPA object without persisting changes
Thanks, Igor - that's very helpful. Not sure how I missed that article while I was searching. It would be a bit tricky to implement in my situation (as I described in another response, the JPA implementation of the data storage is abstracted behind a service API), but I could make it work - perhaps by adding detach and merge methods to the API; that would perhaps expose a little too much of the implementation, but I think that other (hypothetical) implementations could also need to expose similar functionality. Of course, I might be over-engineering this whole abstraction anyways. I have no intention of implementing a non-JPA version - perhaps I should embrace a hard dependency on JPA and simplify everything. JPA is itself an abstraction layer, after all... Thanks, Chris On Wed, Mar 5, 2014 at 11:44 AM, Igor Vaynberg igor.vaynb...@gmail.comwrote: have a look here: https://www.42lines.net/2011/12/01/simplifying-non-trivial-user-workflows-with-conversations/ -igor On Wed, Mar 5, 2014 at 3:47 AM, Chris Snyder chris.sny...@biologos.org wrote: I'm dealing with an issue that I'm sure has been solved by many people on this list, but I'm struggling to ascertain the best way to solve it. I'm working on implementing in-place-edit functionality for some of our site content. The content is stored in a database and mapped via JPA. The edit form has the JPA entity as the backing model object. One of the features I'm implementing is the ability to preview what's been entered in the form without the updates being committed to the database (until the user explicitly clicks on the Save button). I can think of a few ways to accomplish this: 1. Rollback the transaction when not saving - This would require me to manage the transaction manually (right now, they're being managed automatically by Guice's PersistFilter). 2. Detach the object from the persistence context, merge it to save - This seems like the most elegant solution, but I can see how there could be issues (not intractable) with lazy loading. 3. Prevent the form from updating the model until save - This would break my preview panel, and seems to be contrary to how forms normally behave. 4. Copy the data into a non-managed DTO, copying it back to the JPA object on save - Would require a lot of clone/copy code. This seems like such a common problem to solve - I think my relative unfamiliarity with JPA is the main stumbling block here. How have others implemented it? Is there a best-practice pattern that my Googling didn't discover? Thanks in advance for the help. I hope that it isn't too off-topic since it is mainly JPA-related. Best, Chris - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org -- Chris Snyder Web Developer, BioLogos 616.328.5218 x203 biologos.org
Re: Best practice for updating JPA object without persisting changes
you simple need to change where the entitymanager instance lives, and control it via cdi conversation api. no need to expose any more of the jpa stuff. -igor On Wed, Mar 5, 2014 at 9:06 AM, Chris Snyder chris.sny...@biologos.org wrote: Thanks, Igor - that's very helpful. Not sure how I missed that article while I was searching. It would be a bit tricky to implement in my situation (as I described in another response, the JPA implementation of the data storage is abstracted behind a service API), but I could make it work - perhaps by adding detach and merge methods to the API; that would perhaps expose a little too much of the implementation, but I think that other (hypothetical) implementations could also need to expose similar functionality. Of course, I might be over-engineering this whole abstraction anyways. I have no intention of implementing a non-JPA version - perhaps I should embrace a hard dependency on JPA and simplify everything. JPA is itself an abstraction layer, after all... Thanks, Chris On Wed, Mar 5, 2014 at 11:44 AM, Igor Vaynberg igor.vaynb...@gmail.comwrote: have a look here: https://www.42lines.net/2011/12/01/simplifying-non-trivial-user-workflows-with-conversations/ -igor On Wed, Mar 5, 2014 at 3:47 AM, Chris Snyder chris.sny...@biologos.org wrote: I'm dealing with an issue that I'm sure has been solved by many people on this list, but I'm struggling to ascertain the best way to solve it. I'm working on implementing in-place-edit functionality for some of our site content. The content is stored in a database and mapped via JPA. The edit form has the JPA entity as the backing model object. One of the features I'm implementing is the ability to preview what's been entered in the form without the updates being committed to the database (until the user explicitly clicks on the Save button). I can think of a few ways to accomplish this: 1. Rollback the transaction when not saving - This would require me to manage the transaction manually (right now, they're being managed automatically by Guice's PersistFilter). 2. Detach the object from the persistence context, merge it to save - This seems like the most elegant solution, but I can see how there could be issues (not intractable) with lazy loading. 3. Prevent the form from updating the model until save - This would break my preview panel, and seems to be contrary to how forms normally behave. 4. Copy the data into a non-managed DTO, copying it back to the JPA object on save - Would require a lot of clone/copy code. This seems like such a common problem to solve - I think my relative unfamiliarity with JPA is the main stumbling block here. How have others implemented it? Is there a best-practice pattern that my Googling didn't discover? Thanks in advance for the help. I hope that it isn't too off-topic since it is mainly JPA-related. Best, Chris - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org -- Chris Snyder Web Developer, BioLogos 616.328.5218 x203 biologos.org - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
