Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Updating a list of entities #127

Open
DixonDs opened this issue Feb 4, 2015 · 3 comments
Open

Updating a list of entities #127

DixonDs opened this issue Feb 4, 2015 · 3 comments

Comments

@DixonDs
Copy link

DixonDs commented Feb 4, 2015

Currently, if we want to use GraphDiff to update a list of entities, we can only do this in a loop. Is it efficient, given that each graph is loaded by a separate request to the database? Can we make it better if we load a list of entities by a single query?

@ghost ghost added the enhancement label Jul 22, 2015
@ghost
Copy link

ghost commented Jul 22, 2015

Hi,

I haven't thought this through at all, but yes, probably. Have a look at the line of GraphDiffer that's loading the persisted graph via QueryLoader. I'd imagine one could quite easily create an overload to load a collection of graphs using a single query..

@mk1024
Copy link

mk1024 commented Jul 30, 2015

I tried out this idea and it works great in my projects. A large batch process that updates thousands of complex graphs went from 34 to 2 minutes with a batch size of 100. I think I can downgrade to smaller Azure instances :-)

This were my changes (see fork):

  • changing IGraphDiffer and IQueryLoader from T to IEnumerable<T>
  • added additional extension method to DbContextExtensions (existing interfaces not changed)
  • creation of key predicate expression has to be extended to load all persisted entities at once
  • order of persisted/loaded entities can be different from updating entities and must be restored
  • prevent loading of new entities (see pull request)

All existing tests run fine with my changes to GraphDiffer and QueryLoader. Composite keys are still supported ((KeyA='a1' AND KeyB='b1') OR (KeyA='a2' AND KeyB='b2' OR ...) and simple int keys are optimized to ...Key in (1,2,3,4,5...).

@DixonDs
Copy link
Author

DixonDs commented Jul 30, 2015

@mk1024 I think it would be nice if you make a pull request with your changes;)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Development

No branches or pull requests

2 participants