I actually started my code by editing the AuthorOps snippet from
ymnk's GAE version of it. He does reload the nature before editing it:
// Hold a val here so that the "id" closure holds it when we re-enter
this method
bind("author", xhtml,
"id" -> SHtml.hidden(() =>
findAuthor(author) match {
case Some(a) => authorVar(a)
case None =>}),
"name" -> SHtml.text(author.name, author.name=_),
"submit" -> SHtml.submit(?("Save"), doAdd))
findAuthor looks up the the author based on the id in the authorVar
RequestVar, and then sets that back into the authorVar. I wondered why
he did that, and then thought I understood...
Thanks!
On May 19, 5:01 pm, Derek Chen-Becker <dchenbec...@gmail.com> wrote:
> On the first part, I could add a withTx method to LocalEM that would handle
> wrapping the tx for you, if that's OK. Something like:
>
> def withTx[T] (f : => T)
>
> Then you could do
>
> MyEM.withTx {
> prog
>
> }
>
> And it would handle the rollback. How does that sound?
>
> As for the second, if you're getting an exception on the merge I'd really
> like to see the Exception (and code, if possible). Off the top of my head
> the only time that should happen is if you have a constraint violation or
> something similar that would throw and exception even if you were operating
> on a non-detached entity. Take a look at the JPA Demo Library app. It does
> detached object merge all of the time for editing authors and books.
>
> Derek
>
> On Tue, May 19, 2009 at 2:42 PM, ngug <naftoli...@gmail.com> wrote:
>
> > On May 19, 4:31 pm, Derek Chen-Becker <dchenbec...@gmail.com> wrote:
> > > It should already. The closeEM method on both LocalEM and JndiEM checks
> > to
> > > see if the transaction has been marked rollback only and should handle
> > > committing/rollback there. If it doesn't then it's a bug.
> > But we're talking about userTx==true. I mean this:
> > private def transaction(prog: =>Unit) {
> > val tx = EntityManager.getTransaction
> > try {
> > tx.begin
> > prog
> > tx.commit
> > } finally {
> > if(tx.isActive)
> > tx.rollback
> > }
> > }
> > ...
> > def get = transaction {
> > val l = NatureLocationType.lookup(loc.id)
> > l.name = stringValues("name")
> > l.allowStreet = booleanValues("allowStreet")
> > l.allowHospital = booleanValues("allowHospital")
> > l.allowDoctor = booleanValues("allowDoctor")
> > l.allowEquipment = booleanValues("allowEquipment")
> > }
> > (continued below)
>
> > > Also, for your first question:
>
> > > (I take that to mean that setting entity properties does not require a
>
> > > > transaction? I thought that in JPA entities are generally monitored
> > > > for modifications? Is that a mistake?)
>
> > > In the context of a form processing function, the JPA entity is in a
> > > "detached" state at the point that its members are being updated because
> > the
> > > session that it was loaded in (when the form rendered) is now closed. The
> > > transaction is only required when you perform the "merge" of the detached
> > > object into a new session to save the entity data. Whether or not the
> > entity
> > > is actually monitored is an implementation detail, since the spec only
> > says
> > > that when the entity is merged it should save data back to the database,
> > but
> > > it doesn't specify how that is done. Any exceptions related to JPA should
> > > only occur during the flush, or possibly the merge if the JPA provider
> > does
> > > an eager flush to the database. This is why I added the mergeAndFlush,
> > > persistAndFlush, and removeAndFlush methods, so that you would have a
> > > definite place to wrap in a try/catch. If you're doing multiple ops then
> > > you'll need to merge your entire block of merge,persist,remove and flush
> > > methods in a try/catch. Does that make sense? I know that sometimes the
> > > lifecycle of these things can take a few tries to wrap your head around,
> > so
> > > if this isn't clear let me know and I'll try to rephrase.
>
> > I understand you, and that's what I thought too, but I got an
> > exception when I tried to merge a detached entity! If I could get an
> > entity in one request, close the EM, and in the next request just
> > modify it and merge it it would be great, but so far I haven't managed
> > to. If you can't think of any explanation offhand I'll try to
> > reproduce it in an isolated snippet.
> > Thanks!
>
> > > Derek
>
> > > On Tue, May 19, 2009 at 2:07 PM, ngug <naftoli...@gmail.com> wrote:
>
> > > > P.S. I wrote a method to handle the boilerplate of opening/closing/
> > > > checking whether to rollback transactions. Shouldn't ScalaJPA have
> > > > such a method? Or does it?
> > > > Thanks.
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Lift" group.
To post to this group, send email to liftweb@googlegroups.com
To unsubscribe from this group, send email to
liftweb+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/liftweb?hl=en
-~----------~----~----~----~------~----~------~--~---
