Hmmm. It doesn't seem like this should be causing issues. Probably the most
common mistake made with merge is that merge returns an entirely new object,
so you discard the original. Also, if you want the change to be immediately
visible and to check constraints, etc, you need to immediately flush. For
instance:
updateRow (row : Row) : Row = {
Model.merge(row)
Model.flush()
}
It really should be that simple. I'd be happy to look at code if you'd like
to see where there might be issues. I've added some comments below:
On Tue, Dec 9, 2008 at 3:09 PM, Charles F. Munat <[EMAIL PROTECTED]> wrote:
> I set this up so that the user gets a blank row. They can click an "add
> a row" link to add another row. They can click a "-" link at the end of
> each row to remove that row.
I'm assuming that at least this works flawlessly, right?
>
>
> On the server, this creates a new Row() and adds it to the survey
> (Survey.rows.add(new Row())). Then it populates a table row and sends it
> back to the browser.
I'm not 100%, but you may need to actually set the owner field on the row as
well as adding it to the Survey.rows collection. If I remember correctly,
owner fields in objects belonging to collections aren't automatically
updated unless you explicitly set the Cascade property on the collection.
>
>
> I had a TERRIBLE time making this work (and I'm still not convinced it's
> working consistently).
>
> For one thing, the fields in the table update the server on blur using
> AJAX. That was a hassle. Each time I tabbed from one field to the next,
> instead of updating the current Row object, it would create a new one.
> The reason seemed to be because the object was detached. I tried all
> sorts of things: merging, flushing, even trying to pull the row back out
> from the Survey object before merging it. This drove me crazy for two days.
In your add row method, did you persist the new Row before returning it? If
not, it never gets an ID and then when it gets merged it will create a new
instance. I'd have to look at the code to see for sure.
>
>
> Maybe I'm wrong, but the idea of keeping the EntityManager open for the
> duration of the session, manually calling begin and end transaction, and
> only merging and flushing as necessary appeals to me. In this instance,
> I'd push the changes to the database probably on every request to be
> safe, but I'd prefer it if objects didn't detach themselves.
Actually, I think the case of a multi-page form is a good candidate for an
extended session, simply because you would likely want the entire form to be
treated atomically.
>
>
> It would also be nice to be able to create new objects, and then only
> persist them if they need to be persisted. On the above project, I have
> a dirty field on the Row. Each time the page is reloaded, I delete all
> rows that are not dirty, then recreate new rows as necessary. This burns
> up a lot of ids needlessly. It won't make a difference on this survey,
> but it seems a kludgy way to do things.
I'm having trouble visualizing what exactly the dirty flag is representing.
>
> What do you think, Derek? Am I explaining this well enough that you can
> understand what I'm talking about? Is there a simple solution that I'm
> missing? I'm happy to post code if that helps.
>
I think I mostly understand and it sounds like something is probably wrong.
I don't think what you're describing is the intended behavior for JPA.
Derek
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Lift" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/liftweb?hl=en
-~----------~----~----~----~------~----~------~--~---
