Paul,
Deleting an EO is really just like setting a flag until you save, so
this behavior is really no surprise. I've honestly never run into
exactly your use case, but I have run into other situations where it's
important to find EOs that have not yet been saved. A typical
situation for me is where I create an EO if it doesn't exist yet. I
first do a search to make sure it doesn't exist before I create it -
but if it's in the EC and hasn't been saved yet,
objectsWithFetchSpecification won't find it.
Since these situations are usually special cases, I have a method in
my EOEditingContext subclass:
public NSArray unsavedObjectsForEntityAndQualifier(String entityName,
EOQualifier qualifier) {
NSMutableArray result = new NSMutableArray();
Enumeration insertEnum =
this.insertedObjects().objectEnumerator();
while (insertEnum.hasMoreElements()) {
EOEnterpriseObject eo = (EOEnterpriseObject)
insertEnum.nextElement();
if (eo.entityName().equals(entityName) &&
qualifier.evaluateWithObject(eo))
result.addObject(eo);
}
Enumeration updateEnum =
this.updatedObjects().objectEnumerator();
while (updateEnum.hasMoreElements()) {
EOEnterpriseObject eo = (EOEnterpriseObject)
updateEnum.nextElement();
if (eo.entityName().equals(entityName) &&
qualifier.evaluateWithObject(eo))
result.addObject(eo);
}
return result.immutableClone();
}
It doesn't exactly match your needs, but hopefully it will help!
Ken
On Jan 22, 2009, at 3:42 AM, Paul Hoadley wrote:
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 protected])
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/webobjects-dev/kenlists%40anderhome.com
This email sent to [email protected]
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list ([email protected])
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com
This email sent to [email protected]
