Re: When do I use addObjectToBothSidesOfRelationshipWithKey?
Re: When do I use addObjectToBothSidesOfRelationshipWithKey?
- Subject: Re: When do I use addObjectToBothSidesOfRelationshipWithKey?
- From: Chuck Hill <email@hidden>
- Date: Fri, 3 Sep 2004 09:00:21 -0700
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.
_______________________________________________
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.