wicket-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Igor Vaynberg <igor.vaynb...@gmail.com>
Subject Re: Best practice for updating JPA object without persisting changes
Date Wed, 05 Mar 2014 18:15:30 GMT
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.snyder@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.vaynberg@gmail.com>wrote:
>
>> 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.snyder@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-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>
>
> --
> Chris Snyder
> Web Developer, BioLogos
> 616.328.5218 x203
> biologos.org

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org


Mime
View raw message