Re: Creating a fetch that returns the same results as using "session.user.meetings" in WOBuilder
Re: Creating a fetch that returns the same results as using "session.user.meetings" in WOBuilder
- Subject: Re: Creating a fetch that returns the same results as using "session.user.meetings" in WOBuilder
- From: Chuck Hill <email@hidden>
- Date: Fri, 7 Apr 2006 17:37:32 -0700
Hi David,
On Apr 7, 2006, at 5:13 PM, David Holt wrote:
Thanks Chuck,
Merging our last couple of posts:
It does work!!
I'm not sure that it should.
You're killing me!
ROFL!
I suspected it wouldn't work which is why I posted the
clarifications before I tried it. I just substituted the
applicationUsers key and it "just worked". Here's the code:
/** @TypeInfo Meeting */
public NSArray meetingRepetition()
{
ApplicationUser applicationUser = (ApplicationUser)
valueForKeyPath("session.user");
EOEditingContext ec = applicationUser.editingContext();
return EOUtilities.objectsWithQualifierFormat(ec,
"Meeting",
"applicationUsers = %@",
new NSArray(applicationUser));
}
OK, things are starting to get clearer here. For me anyway. When
you do a fetch like this it goes around the relationships in your
model. In other words, the result of this fetch is not necessarily
the same as applicationUser.meetings(). If another process /
application instance has been changed the database (e.g more or fewer
meetings for this user), then applicationUser.meetings() won't
reflect that while this fetch will. Also, if you are not using
addObjectToBothSidesOfRelationshipWithKey, the relationships as
managed by EOF can get out of synch with the database. Again, the
fetch goes to the database so it will return the right result.
Two clarifications: one is that Meeting <-> ApplicationUser is
many to many.
Well, that does make it more tricky. EOF does not come with a
"users contains %@" for qualifying against to-many relationships.
There are options. I suspect that Project Wonder has one. It
seems to have at least one of everything. :-) You can also use
one of Pierre Bernards very clever qualifier extensions found at:
http://homepage.mac.com/i_love_my/webobjects.html
So now I have no idea why the applicationUsers accepted one
ApplicationUser as the argument.
I don't either. Perhaps this was fixed and was not in the release
notes or I forgot about it. Which version of WO? Which database?
Can you turn on SQL logging and post what is being generated for this?
What is the difference between using the code as you gave me and
using the binding out of WOBuilder?
Um, which binding are we talking about?
The "session.user.meetings" variable that I dragged from the lower
part of WOBuilder to the list item of my WORepetition.
If that was not right, then I would suspect editing in another
instance or not using addObjectToBothSidesOfRelationshipWithKey in
your code.
Using the binding seems to delay updating for quite awhile on the
display side, while using the EOUtilities method updated
immediately.
Sounds like your "binding" is caching something.
I'll buy that.
The second is that I am trying to get the fresh data with a
fetchspec.setRefreshesRefetchedObjects(true)
Seeing as how I am lost in the weeds, let me take a step back.
What are you trying to refresh? We need to make a distinction
between
1) Which objects are in the relationship (e.g. have some attendees
been added or removed?)
No change to users. Ideally the user logs in, makes a change to the
meetings schedule. Goes to his home page and sees the updated
meeting information.
2) The attributes of the objects in the relationship (e.g. meeting
time was changed?)
Exacty. For example: Makes a new meeting and invites participants.
Changes a time or location for the meeting.
I don't know if we are communicating. Inviting or excluding
participants from a meeting falls under (1). Changing the meeting
time falls under (2). A refreshing fetch will update the data for
(2). It won't do so for (1), it does not update which objects are in
the relationship, just the qualities of those objects. e.g. It won't
update which meetings a user is scheduled for, only the time of the
meetings they where scheduled for when the fault for user.meetings()
was first fired.
A refreshing fetching will refresh the data for (2) but not (1).
So given that the EOUtilities code shouldn't have worked, can I use
a fetch spec for this?
I'm no longer sure what "this" is. ;-)
A refreshing fetch spec will catch changes to meeting time updates.
It will not catch updates caused by not using
addObjectToBothSidesOfRelationshipWithKey or by another instance
updating the database. See page 96 of Practical WebObjects for one
way of refreshing to-many relationships.
Chuck
--
Coming in 2006 - an introduction to web applications using WebObjects
and Xcode http://www.global-village.net/wointro
Practical WebObjects - for developers who want to increase their
overall knowledge of WebObjects or who are trying to solve specific
problems. http://www.global-village.net/products/practical_webobjects
_______________________________________________
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