Hi, Frederic,
I agree with all who are recommending "the WO way" of inserting your
EOs into an editing context as soon as it's created. However, this
can seem a bit daunting if you haven't been using peer or child
editing contexts before, given the number of messages on the list
about not properly locking the editing contexts that you create.
The general problem has been solved, however, in two ways:
* Project Wonder's ERXEC
* Jonathan Rochkind's MultiECLockManager
If you want deep background on the problem and its solutions, take a
look at:
http://en.wikibooks.org/wiki/Programming:WebObjects/EOF/
Using_EOF/Context_and_Database_Locking
However, if you just want to solve your immediate problem and haven't
yet bought into Project Wonder (which you should probably do soon),
then I would suggest peer editing contexts, MultiECLockManager and
would offer you the following notes:
===================================
// ****** Add the MultiECLockManager class to your project from the
following site ********
http://www.wocode.com/WOCode/Files/MultiECLockManager.java
// ****** Add the following code to Session: ********
// Add the following import statements:
import com.webobjects.eoaccess.*;
import java.lang.*;
import java.util.*;
// Define this ivar:
private MultiECLockManager meclm;
// Create a new lock manager in the Session initialization after
"super();"
setLockManager(new MultiECLockManager());
// Add these methods to Session:
public MultiECLockManager lockManager()
{
return meclm;
}
public void setLockManager(MultiECLockManager newLockManager)
{
meclm = newLockManager;
}
public void awake()
{
super.awake();
lockManager().lock();
}
public void sleep()
{
if ( lockManager() != null )
lockManager().unlock();
super.sleep();
}
public void terminate()
{
lockManager().unlock();
meclm = null;
super.terminate();
}
// ****** Add the following code to a WOComponent that creates its
own ec: ********
// Define the EC ivar:
private EOEditingContext ec;
// Create & register the new EC in the component's initialization
method after "super(context);"
ec = new EOEditingContext();
((Session)session()).lockManager().registerEditingContext(ec);
// Be sure to pass your newly created EC to any subsequent
WOComponents needed for a multipage transaction.
===================================
Create a new editing context in any WOComponent that initiates a new
logical transaction for the user. Do your ec.saveChanges() in some
method of that component triggered by a Save button on the page. If
the transaction requires more than a single page, pass your new
editing context to each page in succession until the last page does
the ec.saveChanges().
These notes don't represent the only way to implement
MultiECLockManager, but they work well for the general case and if
you use them initially, you can refine your approaches over time as
more esoteric cases appear.
As others have said, if your user starts a transaction and goes away
before finishing it and doing the ec.saveChanges(), all of the EOs
that they've created, all of the changes that they've wrought on that
resulting object graph, and all the delete's that they've incurred
are simply forgotten with no effect on your object store and no
effect on your other editing contexts.
Very handy.
Regards,
Jerry
On May 30, 2007, at 7:20 AM, Frederic JECKER wrote:
Hi,
In my case, I can't insert objects in the editing context at their
creation but only at the end of the transaction because the user
can cancel his action at any time.
Doing as decribed works (I do it myself) but if I do so, I will
need to call at editingContext.revert()
to prevent unwanted changes to be saved in the database by another
part of my app using the same context.
To sum up, I'm just looking for a method like
EOEditingContext.awakeFromInsert except that it would be called
before inserting objects instead of after.
This way I could insert relationship members in the editingContext
for each EOCustomObject in their own classes and avoid huge code
blocks of insert
in my main controller
Regards
FJ
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (Webobjects-dev@lists.apple.com)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/webobjects-dev/jerrywwalker%
40gmail.com
This email sent to [EMAIL PROTECTED]
--
__ Jerry W. Walker,
WebObjects Developer/Instructor for High Performance Industrial
Strength Internet Enabled Systems
[EMAIL PROTECTED]
203 278-4085 office
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (Webobjects-dev@lists.apple.com)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com
This email sent to [EMAIL PROTECTED]
