On Feb 15, 2008, at 1:12 PM, Florijan Stamenkovic wrote:
It seems like it's making the trip to the server, and making it as far as executing getFetchSpecification, but then fails and prints the exception above.
What makes you say that? Seems to me that the stack trace stops on the client side, just at the moment it needs to send a request to the server. Or am I missing something?
Okay, the borken pipe was a Red Herring. Just cooincidental to me adding a logging statement. It has since mysteriously disappeared.
It is definitely making it to the server because I added this logging statement to the server-side Session class:
NSLog.out.appendln("About to call FetchSpecification " + spec);
and I get a nice "About to call FetchSpecification USDACalories" in the server console.
But it's returnning null. When I call the same FS using DBEdit (god, I'm going to miss that tool when I move to leopard) I get exactly what I'm expecting, which would be one instance of NutritionElementType that is the one for USDACalories.
So, what's different between my app pulling the FS from the EOModel in the Session class, and DBEdit doing it?
My next try is to do a stateful RMI request, the more traditional way using the invokeRemoteMethod() method on EOCustomObject and see what it comes back with. Even though that will push my EditingContext back up to the server, which is not what I want calling a FS to do normally. I suppose I could just hard-code the FS also...
Dave