Re: InsertObject
Re: InsertObject
- Subject: Re: InsertObject
- From: Mark Morris <email@hidden>
- Date: Wed, 30 May 2007 10:49:01 -0500
I might have missed something, but for his case I'm not sure he needs
anything more than the default editing context, and since he's new to
some of the concepts, that might be easier.
Frederic, I usually just use the EOUtilities.createAndInsertInstance
method to take care of both creation and inserting into the editing
context at the same time. Using session's defaultEditingContext,
locking and such are handled for you. And you can still revert() to
undo changes, without saving them to the DB, back to the previous
saveChanges().
Now, there are some advantages to creating a peer or child editing
context and being able to dispose of the whole thing. I'm just
saying I think this will work for you, and you can investigate the
other options as you go forward.
Regards,
Mark
On May 30, 2007, at 8:26 AM, Jerry W. Walker wrote:
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 (email@hidden)
Help/Unsubscribe/Update your Subscription:
40gmail.com
This email sent to email@hidden
--
__ Jerry W. Walker,
WebObjects Developer/Instructor for High Performance Industrial
Strength Internet Enabled Systems
email@hidden
203 278-4085 office
_______________________________________________
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