Behaviour of objectsWithFetchSpecification()
Behaviour of objectsWithFetchSpecification()
- Subject: Behaviour of objectsWithFetchSpecification()
- From: Paul Hoadley <email@hidden>
- Date: Thu, 22 Jan 2009 19:12:25 +1030
Hello,
I've run into some EOF behaviour that I certainly didn't expect.
1. Say I have an entity Foo with an optional to-one relationship to
Bar. There is no inverse relationship.
2. I have a particular Foo in an EC. I've deleted it with
someFoo.editingContext().deleteObject(someFoo), and also called
someFoo.setBar(null).
3. I have not called saveChanges(), as there is more to do.
4. In particular, I now need a list of any Foos with a relationship
to the Bar in the relationship I just nulled. So I use the template
method Foo.fetchFoos(), passing in the same EC, a qualifier to match
Foo.BAR_KEY to theBar, and no sort ordering.
5. What I get back is an array containing someFoo---the EO I've
deleted. someFoo.isDeletedEO() returns true, and someFoo.bar()
returns null.
Reading the API for objectsWithFetchSpecification(), I guess this
should be completely unsurprising: it "fetch[es] objects from an
external store according to the criteria specified by fetchSpec"---
someFoo is still present in the external store, as I have not called
saveChanges(), and its state in the external store would match the
fetchSpec because the FK reference is still there. All it promises is
that the in-memory state of someFoo will not be overwritten, _not_
that the in-memory state of someFoo will be checked against the
fetchSpec.
I guess I'm just asking for a sanity check. This can't be an uncommon
use case---what do people do next? Use
EOQualifier.filteredArrayWithQualifier() on the result? Am I
overlooking something basic?
--
Paul.
w http://logicsquad.net/
h http://paul.hoadley.name/
_______________________________________________
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