Re: Object not being saved after refaulting and applying changed
Re: Object not being saved after refaulting and applying changed
- Subject: Re: Object not being saved after refaulting and applying changed
- From: Jeff Schmitz <email@hidden>
- Date: Sun, 30 Nov 2008 13:57:20 -0600
Hello,
I'm using the TolerantEditingContext:
EOEditingContext ec = ERXEC.newTolerantEditingContext();
And was wondering exactly what it means to 'merge' changes with the
database? Looking at the Wonder code, It looks like the default
options should be retry=true and merge=true. Does merge mean that if
an update exception occurs (i.e. something about the record being
updated was changed elsewhere) it will only merge attributes that were
actually changed by the user? Or does it update the entire record
being saved by the later user, i.e. last in wins?
The reason I ask is, it seems from testing that if I bring up the same
record on my site in two different sessions and change an attribute on
one page and save it, and then do a save on the other page without
changing anything, the attribute that was changed on the first update
gets overwritten by the original (now stale) value that was brought up
by the second session, even though no attributes were changed. To me,
this sounds like the "stomp" option from the description below.
I was hoping it would check what changed from when the page was first
brought up and merge only those changes with the values from the
refaulted data that was brought in from the DB when the exception
occurred. Asking too much? Or is there something else I need to do
to get this behavior?
Thanks,
Jeff
On Jul 20, 2007, at 3:48 PM, Chuck Hill wrote:
Yes, I know. :-) Where do you think the Wonder code came from?
/**
* This class is pulled directly out of David Neumann's
* ChangeNotification framework. The only changes made are
* to use log4j instead of System.out.println.<br/>
* <br/>
* The tolerant saver provides a way to save an editing context in
* a tolerant fashion. By tolerant we mean that you can have the
* option to save an editing context and have the exception ignored,
* hvae the changes merged from the database or stomp all the changes
* the database regardless of locking. The entry point for using this
* class is the <code>save</code> method.
* @deprecated use ERXEC
*
*/
public class ERXTolerantSaver {
On Jul 20, 2007, at 1:43 PM, Galen Rhodes wrote:
This is actually what I was thinking of: http://www.wodeveloper.com/sourcecode/cn_readme.html
The tar file contains a standalone class called TolerantSaver.
It's pretty old so I don't know if it'll work with 5.3 or not but
it seems worth a try if he's looking for quick solution.
--
Galen Rhodes
email@hidden
"There is no worse tyranny than to force a man to pay for what he
does not want merely because you think it would be good for him."
-- Robert Heinlein --
On Jul 20, 2007, at 4:33 PM, Mike Schrag wrote:
You access this via ERXEC's newTolerantEditingContext factory
method, btw. I think there's a way to make that the default, but
I'd have to look it up.
ms
On Jul 20, 2007, at 4:24 PM, Chuck Hill wrote:
Wondering :-P where that is?
er.extensions.ERXTolerantSaver.java
On Jul 20, 2007, at 1:16 PM, Galen Rhodes wrote:
Years and years and years ago I could have sworn someone posted
a method that replaced EOEditingContext.saveChanges() that
would apply (merge) recent database changes to changed EOs if
they failed optimistic locking?
I think this was around 2001 or so.
I think it was basically what Miguel is looking for in one easy
to use method.
--
Galen Rhodes
email@hidden
"There is no worse tyranny than to force a man to pay for what
he does not want merely because you think it would be good for
him."
-- Robert Heinlein --
On Jul 19, 2007, at 7:19 PM, Chuck Hill wrote:
On Jul 19, 2007, at 4:17 PM, Miguel Arroz wrote:
Hi!
Pardon my ignorance, but is there a way to apply this
globally? IE, change the behaviour of all the ECs to this?
You could add it to a sub-class of EC. I have _no_ idea what
this would do to EOF internals, but I would not be at all
optimistic for success.
I will actually used an optimized version of this to (try to)
solve my problem, because I can reduce the number of fetches,
but it would be nice to know that this would work fine
everywhere.
This is just an extract from how I handle optimistic locking
problems.
Chuck
PS: Pierre, it would be *really* great to have that bug
fixed! ;)
4. Try this instead of refault:
/**
* Forces this object to be re-read from the database; the
snapshot and all editing contexts
* holding this object are updated. Merging or overwriting
of the changes is then handled by
* the editing context delegate. This method takes no
action if the object is pending insertion.
*
* @param anObject the object to be evaluated
*/
public static void refreshObject(EOEnterpriseObject
anObject)
{
/** require [valid_theObject_param] anObject != null;
[in_ec] anObject.editingContext() !=
null; **/
// We can't just call editingContext().refreshObject()
or editingContext().refaultObject() the object here.
// That will result in fresh data only if the object
is in a single editing context.
// This seems like the safest way to get fresh data
and inform all of the other
// editing contexts that they need to update.
EOEditingContext ec = anObject.editingContext();
if ( ! ec.insertedObjects().containsObject(anObject))
{
EOQualifier thisObject =
EOUtilities.qualifierForEnterpriseObject(ec, anObject);
EOFetchSpecification fetchSpec = new
EOFetchSpecification(entityForSelf(anObject).name(),
thisObject, NSArray.EmptyArray);
fetchSpec.setRefreshesRefetchedObjects(true);
anObject
.editingContext().objectsWithFetchSpecification(fetchSpec);
}
}
--
Practical WebObjects - for developers who want to increase
their overall knowledge of WebObjects or who are trying to
solve specific problems.
http://www.global-village.net/products/practical_webobjects
Miguel Arroz
http://www.terminalapp.net
http://www.ipragma.com
--
Practical WebObjects - for developers who want to increase
their overall knowledge of WebObjects or who are trying to
solve specific problems.
http://www.global-village.net/products/practical_webobjects
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
--
Practical WebObjects - for developers who want to increase their
overall knowledge of WebObjects or who are trying to solve
specific problems.
http://www.global-village.net/products/practical_webobjects
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
--
Practical WebObjects - for developers who want to increase their
overall knowledge of WebObjects or who are trying to solve specific
problems.
http://www.global-village.net/products/practical_webobjects
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden