Is there any way I can tell EF to not worry about the number of rows a DELETE or UPDATE do or don't do?

I'm trying to delete a row from the database, but because the row doesn't exist, EF throws an exception: DbUpdateConcurrencyException .. saying 0 rows were affected. This is right -> no rows were deleted. But that's totally fine .. cause there's no data.

I don't really want to do a round-trip to the DB to see if that row exists .. and if so .. then try and delete it.

If i try and swallow the exception in a try / catch block, then the rest of the items to be deleted do NOT get sent to the db, when I try to SaveChanges() ... which is bad.

eg.

Delete(new Foo(1));
Delete(new Foo(2));
Delete(new Foo(3));
SaveChanges(); // <-- Throws the exception.

// DB Trace : DELETE FROM Foo WHERE Id = 1;

and thats it.. there's no trace showing record 2 or 3 trying to get deleted .. because the exception stops everything :(

Any ideas?

UPDATE

How does Delete work? Here's the code... (simplified and strongly typed)

public void Delete(Foo foo)
{
    if (foo == null)
    {
        throw new ArgumentNullException("foo");
    }

    Foo attachedEntity = Context.Set<Foo>().Local.FirstOrDefault(x => x.Id > 0);

    if (attachedEntity != null)
    {
        // Entity already in object graph - remove entity.
        Context.Set<Foo>().Remove(attachedEntity);
    }
    else
    {
        // Entity not in object graph, attach and set EntityState to Deleted.
        Context.Entry(foo).State = EntityState.Deleted;
    }
}
Edit
Report