Simpler Delete of entities

[Burgyn]

Starting discussion about Simplier Delete of entities from #8.

---

Now, if we want to delete an entity, we can use direct SQL statement (ExecuteNonQuery), or DbSet. The disadvantage of ExecuteNonQuery is, that it does not have ane knowledge about entity type, so the SQL must be hand written. Disadvantage of DbSet is that we need to create an instance of the entity, just to have its ID. I'd like to have something which can be used without creating an entity instance:

_database.Delete<EntityType>(123)

We could support delete with condition (instead of just primary key):

_database.Delete<EntityType>(item => item.ParentId == 123);

Things to think about:

• Where to implement this (IDbSet, IDatabase...). And it should at least support int and long primary keys (generic of <TEntity, TKey>?), but better any keys (what about composite ones?).
• What kind of expressions to support when deleting with condition and throw some exception if we cannot translate it into SQL.

ToDo:

• Delete by id
  • Check if id has the same type as primary key property
• Integration test for Delete by id
• Delete by condition
  • Prototype
  • Implementation
  • Unit and integration tests
  • xml comments
• Extension for easy calling Delete and Add operation.
• Info to readme file.

[Burgyn]

I started to think about it.

I suggest:
To maintain consistency, we implement these methods in DbSet, like others (Delete, Edit, Add). The records are not deleted immediately, but only after you confirm the changes with CommitChanges().

For easier calling in common situations we can create extension methods over IDatabase, which allow easy adding and deleting of records. This extension method wraps work with DbSet and makes it easy to call _database.Add(new Entity());, _database.Delete<EntityType>();

We will have the following new overloads of the Delete method:

Delete(object id);
Delete(Expression<Func<T, bool>> condition);
Delete(string whereCondition, params object[] parameters);

We will not use the generic type for the primary key type. Because it is eventually set to the command parameter as an object, so it's already boxing.

We do not support the composite key. In the case of a composite key, the developer will need to use the entity.

@satano what do you think?