What's use of it if there's already change tracker in EF core?

[bugproof]

No description provided.

[tonysneed]

@enemyofthedawn EF Core has the ability to traverse an object graph using the TrackGraph method, but you have to supply a function pointer telling EF what to do on each node of the object graph. EF Core does not have any built-in mechanism for setting change state on the client in a way that it can be serialized and read on the server side. What Trackable Entities does is supply the mechanism for setting change state on the client, so that it can be serialized and sent to the service where it can inform EF of the change state, so that changes to an entity graph can be persisted in one round trip and within a single transaction.

Trackable Entities has a TrackingState enum with values for Unchanged, Added, Modified and Deleted. Each entity has a TrackingState property with values set by the client before sending entities to the service. Then the service can use the ApplyChanges extension method to DbContext to set the EF EntityState of each entities based on the TrackingState value. In order to do this, TE internally calls the TraverseGraph EF Core method, reading TrackingState and converting it to EntityState for the EF Core change tracker.

Hope this clears things up.

[bugproof]

Oh I see now, so you can control tracker state from the client. I don't think I will need it. Thanks for clarifying :)