All,
Anyone see a use for entity-scope commit methods I'm setting up a gui editor and it would be nice to reject changes on a per-entity basis and know the remaining graph is preserved. If so, then it follows to add the per-entity SubmitChanges() method.
That may call for a root entity class (which the DLinq design seems to avoid).
public class RootEnttiy
{
public void SubmitChanges() {}
public void RejectChanges() {}
}
public class CustomEntity : RootEntity {}
Or, perhaps pass the entity to the DataContext.
CustomEntity ce = new CustomEntity();
ce.Text = "Ok";
dataContext.RejectChanges(ce);
ce.Text = "Yup";
dataContext.SubmitChanges(ce);
Cheers,
Rana
Entity-scope RejectChanges()?
Raj_Singh
Given the object model that DLinq uses, where all database API is on the context leaving the entity classes relatively independent, I'd vote for the second variant.
thiszhw
Perhaps it's hard to implement relation-related CRUD operations, because entity relations can make up a complex graph. For example,
ChildEntityClass cec = new ChildEntityClass();
ParentEntityClass pec = ... ;
pec.AddChild(cec);
// Entity relations
dataContext.SubmitChanges(pec); //or dataContext.RejectChanges(pec);
// or dataContext.SubmitChanges(cec);
I also like to have a similiar feature like:
dataContext.Refresh(sqlQuery);
that execute the query and simply replace related entities that the DLINQ's change tracking service have marked changed (but for some reason call to SubmitChanges() failed.) So I do not need to create a whole new DataContext when submit fails.