Re: why ec.refreshAllObjects() required?
Re: why ec.refreshAllObjects() required?
- Subject: Re: why ec.refreshAllObjects() required?
- From: Drew Thoeni <email@hidden>
- Date: Tue, 22 Feb 2005 18:07:10 -0500
Jean-François,
Thanks. The other many-to-many relationships for these objects are not flattened (there are only these two). There are, however, one-to-many relationships.
I think I am going to try to identify the relationship that is failing to update by using refreshObject() on selected objects and testing them each.
Regards,
Drew
On Feb 22, 2005, at 9:32 AM, Jean-François Veillette wrote:
Refresh (other than update the attributes values themselfs) can be used to reset relationships.
A relationship (a NSArray), once fired (no longer a fault) is a kind of cache of the values at that time.
For example, we need to add to both sides of relationship because we want our newly inserted object in both cache. If the relationship content where dynamic (qualified fetched everytime), we wouldn't need to be so carefull about adding to both sides of a relationship.
From what i see in the code bellow, you add to both sides of your relationships, so all should be good. So I guess the problem is not shown here, I guess you have a flattened relationship that is causing problem once cached (once the nsarray fault fired).
Do you have a flattened relationship from student to book ? or from Student to class ? that would be one kind of relation that would need to be refreshed.
- jfv
Le 05-02-22, à 07:00, Drew Thoeni a écrit :
I have some code (below) that adds to two many-to-many relationships. I can run it once (and it's twin that removes these entries) and it works just fine. But, when I run it the second time, the tables get updated but the ec does not. When I add the line "ec.refreshAllObjects()" I can then add and remove the relationships as many times as I want and all is well in the tables and ec.
Generally when I find a situation like this I attribute it to my shallow understanding of WO. If it is critical or mysterious enough, I ask the all-knowing list. Occasionally it turns out to be some oddity in WO. Which is it here?
Regards,
Drew
// Note: This method is resides in the "Class" table (an unfortunate name) and is called from
public void joinClass(EOEditingContext ec, Application application, Session session) {
// This method adds a student to class (inserts a row into ClassStudent) and
// Adds an entry into BookStudent for each book this student has for this class.
// this step-by-step join is to allow awakeOnInsertion to set variables in this unflattened table.
ClassStudent newGPJoin = (ClassStudent)EOUtilities.createAndInsertInstance(ec,"ClassStudent");
session.currentStudent.addObjectToBothSidesOfRelationshipWithKey(newGPJoin,"classStudents");
this.addObjectToBothSidesOfRelationshipWithKey(newGPJoin, "classStudents");
// add relationship into table BookStudent, student to each book, and set class number.
NSArray tempBookList = this.books();
int count = tempBookList.count();
Book tempBookItem = (Book)tempBookList.objectAtIndex(0);
int i = 0 ; i < count ; i++) {
//Make a new bookStudent Object
BookStudent newCPJoin = (BookStudent)EOUtilities.createAndInsertInstance(ec,"BookStudent");
newCPJoin.setClassNumber(this.classNumber());
session.currentStudent.addObjectToBothSidesOfRelationshipWithKey(newCPJoin,"bookStudents");
((Book)tempBookList.objectAtIndex(i)).addObjectToBothSidesOfRelationshipWithKey(newCPJoin, "bookStudents");
}
ec.saveChanges();
ec.refreshAllObjects(); // WITHOUT THIS LINE, CODE WILL NOT WORK REPEATEDLY.
this.embargoClassIfNeeded(ec, application, session);
}
_______________________________________________
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