.
--
From: Derek Chen-Becker dchenbec...@gmail.com
Sent: Tuesday, May 26, 2009 3:09 PM
To: liftweb@googlegroups.com
Subject: [Lift] Re: Trouble with lift, GAE, JPA, adding child records
The merge method really should be able to handle this, so could you provide
some code that shows how you're
To: liftweb@googlegroups.com
Subject: [Lift] Re: Trouble with lift, GAE, JPA, adding child records
I wonder if that's something specific to GAE. Typically what I do using the
Hibernate EM is something like:
val current = myAuthor // this entity has either been passed in or
retrieved
bind (author
Sorry for the delay in responding. My question was not about
transaction API, my question was a practical one: If form processing
is split into a bunch of little anonymous functions, how can you put
them in a try/finally?
On May 15, 1:59 pm, Derek Chen-Becker dchenbec...@gmail.com wrote:
Well, typically the form callbacks are just setting values. If they're more
complex than that then you would need a try/catch in each function. I don't
think that the current form processing code has any facility for a per-form
exception handler, although that might be a useful feature.
Derek
On
Thanks for the fast response! Okay, a couple of things:
1.
Well, typically the form callbacks are just setting values. If they're more
...
(I take that to mean that setting entity properties does not require a
transaction? I thought that in JPA entities are generally monitored
for
בה using the FormProcessor, all my exceptions seem to have
disappeared. Now I have a problem, that although seems to be a
separate problem is very much intertwined with everything else and I
think it's really one issue.
The page basically looks like this:
Nature Name: [text field]
Locations:
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
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.
Also, for your first question:
(I take that to mean that setting entity properties does not
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
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
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(() =
One entity group per transaction is a GAE requirement. But my question
about handling transactions was more specific - because form
processing is specified piecemeal in separate closures, you can't
use the normal try/finally. It seems a little too much effort to
create a hidden field before and
EntityManager has a getTransaction method that you can use along with the
constructor I mentioned previously to explicitly begin and end transactions
in your code.
derek
On Fri, May 15, 2009 at 11:45 AM, ngug naftoli...@gmail.com wrote:
One entity group per transaction is a GAE requirement.
In any case, how would I handle transactions manually? An SHtml.hidden
before and after every form? It's confusing because SHtml lumps the
get and set side by side when they happen in two different requests
and the entity needs to be reloaded in between. In any case, GAE seems
to require tighter
In any case, how would I handle transactions manually? An SHtml.hidden
before and after every form? It's confusing because SHtml lumps the
get and set side by side when they happen in two different requests
and the entity needs to be reloaded in between. In any case, GAE seems
to require tighter
In any case, how would I handle transactions manually? An SHtml.hidden
before and after every form? It's confusing because SHtml lumps the
get and set side by side when they happen in two different requests
and the entity needs to be reloaded in between. In any case, GAE seems
to require tighter
I guess I should include the views too to make it easier to reproduce
the problem. Here is edit.html:
lift:surround with=default at=content
head
titlelift:loc
lift:Natures.newOrEdit
if:editEdit/if:edit
I took a quick look and nothing is jumping out at me as wrong. When you get
these errors do you at least get a stack trace? Having that would help
narrow down where it's happening.
Derek
On Tue, May 12, 2009 at 5:40 PM, ngug naftoli...@gmail.com wrote:
I made the beginnings of a lift app for
Thanks for looking. The stack traces aren't very helpful because they
concern the state which is caused by the previous sequence of events.
Anyway, why is there a transaction taking place in the first place?
--~--~-~--~~~---~--~~
You received this message because
JPA requires that a transaction be in place before *any* persistence
operations occur. The ScalaJPA stuff is supposed to handle it for you, so
that's why I was wondering about stack traces. In particular, the
RequestVarEM trait should start a new transaction when the request begins
and close the
20 matches
Mail list logo
