Re: When do I use addObjectToBothSidesOfRelationshipWithKey?
Re: When do I use addObjectToBothSidesOfRelationshipWithKey?
- Subject: Re: When do I use addObjectToBothSidesOfRelationshipWithKey?
- From: Dirk Bajohr <email@hidden>
- Date: Fri, 3 Sep 2004 18:32:55 +0200
Thanks for your explanation, Chuck, just some simple questions to
understand the "ec confusion":
#1
Say I have an EO in the session default EC and modify some values. Then
I migrate the object to another ec (before saving the changes), let's
call it ec2. All changes from the default EC are visible in ec2, right?
#2
The same as in #1, but after having the object in ec2 I change values
in the default ec. Are they visible to ec2?
#3
What happens if I call save changes on the default ec before saving
changes on ec2 if I modified values in ec2?
Thanks in advance,
Dirk
P.S. your book is not yet available here in Germany :-(
Tom, the updated code will look like this (with awake() and sleep()
added):
public class MyComponent extends WOComponent {
EOEditingContext tempEC;
Request req;
... constructor etc. ...
public void appendToResponse(WOResponse aResponse, WORequest
aRequest) {
tempEC = new EOEditingContext();
req = new Request();
tempEC.insertObject(req);
super.appendToResponse(aResponse, aRequest);
}
public void awake() {
super.awake();
tempEC.lock();
}
public void sleep() {
tempEC.unlock();
super.sleep();
}
public NSArray reqStatusList() {
return EOUtilities.ObjectsForEntityNamed(tempEC, "ReqStatus");
}
public WOComponent save() {
try {
tempEC.lock();
tempEC.saveChanges();
} catch (Exception e) {
...
} finally {
tempEC.unlock();
}
tempEC = null;
return context().page(); // or: return pageWithName("Whatever");
}
}
Am 03.09.2004 um 18:00 schrieb Chuck Hill:
Dirk,
Your EC locking is not correct. It is not only around calls to
EOEditingContext methods but also to all calls to methods on EOs in
the editing context. The EC needs to be locked around the time awake
is called, and unlocked around the time that sleep is called. I
suggest using the MultiECLockManager. You can find this on
www.wocode.com
Chuck
On Sep 3, 2004, at 8:32 AM, Dirk Bajohr wrote:
This is one way to accomplish this, another (I think the better)
approach would be to create a new Request and to insert it into an
EditingContext before the page is displayed.
Then you can bind the object's relationships directly. Your save
button only needs to call ec.saveChanges().
And if you use an EditingContext different from the session's default
one and the user doesn't click on the save button, no changes are
made to the database and the object graph of your default ec is still
"clean".
But don't forget to call the lock() and unlock() functions for the
custom ec when you save the changes.
And BTW all other objects have to be in the same ec.
The Request objects that you display in the list below will stay in
the defaultEC.
A short example?
public class MyComponent extends WOComponent {
EOEditingContext tempEC;
Request req;
... constructor etc. ...
public void appendToResponse(WOResponse aResponse, WORequest
aRequest) {
tempEC = new EOEditingContext();
req = new Request();
tempEC.insertObject(req);
super.appendToResponse(aResponse, aRequest);
}
public NSArray reqStatusList() {
return EOUtilities.ObjectsForEntityNamed(tempEC, "ReqStatus");
}
public WOComponent save() {
try {
tempEC.lock();
tempEC.saveChanges();
} catch (Exception e) {
...
} finally {
tempEC.unlock();
}
tempEC = null;
return context().page(); // or: return pageWithName("Whatever");
}
}
Am 03.09.2004 um 16:05 schrieb Tom Jones:
Thank you,
Just to clarify...
I have an app that is similar in design to the Author/Book example
in
Apple's documentation. So the first row of the table the user enters
the info, and the second row is a WORepetition that shows all of the
items(in this case reqs).
In the input row, I bind everything to the various fields in a req.
req.status is bound to a WOPopup's selection. I take it from your
email that it would be better to have an object for each of the
Relationships, and bind the inputs to these objects and then make the
association. So for instance, bind aStatus to the WOPopup's
selection,
and then call aStatus.addObjectToBothSidesOfRelationshipWithKey(req,
"reqs"); Right?
Thanks,
Tom
On Thu, 2 Sep 2004 14:00:38 -1000, Art Isbell <email@hidden>
wrote:
On Sep 2, 2004, at 1:00 PM, Tom Jones wrote:
The code below is my attempt to preserve the following
relationships
project<-->>req
reqpriority<-->>req
status<-->>req
reqtype<-->>req
a project owns its reqs
if a reqpriority, status or reqtype is deleted, the req's
corresponding value should be null.
given that is all of this code necessary?
session.defaultEditingContext().insertObject(req);
req.reqpriority().addObjectToBothSidesOfRelationshipWithKey(req,
"reqs");
req.status().addObjectToBothSidesOfRelationshipWithKey(req,
"reqs");
req.reqtype().addObjectToBothSidesOfRelationshipWithKey(req,
"reqs");
project.addObjectToBothSidesOfRelationshipWithKey(req,"reqs");
session.defaultEditingContext().saveChanges();
Statements 2 - 4 imply that req.reqpriority, req.status, and
req.reqtype have already been set, so there's no need to set them
again
(however, property values should in general be set after only an
object
is inserted). If they haven't been set, statements 2 - 4 should
throw
a null exception.
If you have reqpriority, status, and reqtype objects,
statements 2 - 4
should be:
reqpriority.addObjectToBothSidesOfRelationshipWithKey(req, "reqs");
status.addObjectToBothSidesOfRelationshipWithKey(req, "reqs");
reqtype.addObjectToBothSidesOfRelationshipWithKey(req, "reqs");
Aloha,
Art
_______________________________________________
webobjects-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/webobjects-dev
Do not post admin requests to the list. They will be ignored.
_______________________________________________
webobjects-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/webobjects-dev
Do not post admin requests to the list. They will be ignored.
--
Dirk Bajohr
iSOLUTION - Individuelle Software fuer moderne Kommunikation
Hauptstr. 50
53757 Sankt Augustin
T +49 2241 921567-0
F +49 2241 921567-89
http://www.isolution.de
_______________________________________________
webobjects-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/webobjects-dev
Do not post admin requests to the list. They will be ignored.
--
Dirk Bajohr
iSOLUTION - Individuelle Software fuer moderne Kommunikation
Hauptstr. 50
53757 Sankt Augustin
T +49 2241 921567-0
F +49 2241 921567-89
http://www.isolution.de
_______________________________________________
webobjects-dev mailing list | email@hidden
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/webobjects-dev
Do not post admin requests to the list. They will be ignored.