none
Are there alternatives for "Attach" and "AttachTo"? RRS feed

  • Question

  • I need to attach hundreds or more entities to my object context at once. Using the standard methods "Attach" or "AttachTo" this takes quite a while.

    Is there a more efficient way to attach large entity collections to the object context than by using these methods? My entities do not need to get change tracked?

     

    Saturday, June 18, 2011 9:34 AM

Answers

  • Well,

    One of the things I have experienced using special approaches like this (which Self-Tracking Entities does a lot) is that I get unexpected errors in conjunction with SaveChanges and invalid states for the entities. These errors isn't always easy to find. But as long as you have control of this I think you should be ok.

    The easiest way to have control is to have your context so short lived as possible to avoid to many operations against it.


    --Rune
    Monday, June 20, 2011 7:37 AM

All replies

  • Hi,

    No, there isn't any other way to attach them to the context, you need to attach them one at a time. Even if you don't need tracking, EF needs this to determine the update operation to pass down to the database. EF is not optimal to use if you want to pass large amount of data to the database.

    If your wish is only to update the database in a bulk, you should consider using SqlBulkCopy in ADO.NET instead of using EF (http://msdn.microsoft.com/en-us/library/system.data.sqlclient.sqlbulkcopy.aspx). Note, this is only for SQL server.

     


    --Rune
    Saturday, June 18, 2011 5:35 PM
  • Hi,

    Thanks for your reply. I was afraid for that answer :-)

    The thing is I don't need this bulk attach for adding data to my database, but the other way around. I've an alternative query mechanism and want to attach the resulting entities of my query to the object context in the fastest way possible. I was hoping for some low-level interface or something to accomplish this.

    Thanks again.

    Merijn

    Saturday, June 18, 2011 5:47 PM
  • Hi again!

    No, not anyone I know of anyway...

    But I'm curious about why you want to map them if you don't want to changetrack them?

    I think that it is better for you to have it in memory, and join the result outside EF. Remember, that even if entities does exist in your context, a query against your context will try to retrieve information from your database even if the entities is in your context already. And in addition, if you call SaveChanges on your context for some reason which contains these entities and they for some reason unintensional got a state other than unchanged, they will be sent to your database.


    --Rune
    Sunday, June 19, 2011 7:15 AM
  • Hi,
    Let me explain. There are two reason why I want to map the entities in the object context:

    1. I want EF to reconstruct the graph of entities (i.e., the navigation properties that allow me to navigate from one entity to another). I could do this my self but why reimplementing this functionality if EF already supports it. But also because
    2. I want my query mechanism to seamlessly integrate with EF. My goal is that you can use this querying mechanism for querying and for all the rest you use EF. Therefore the entities that result from my query must be attached to an EF object context.

    My remark about not needing change tracking is actually not completely correct. It is because of my concrete use of the query mechanism. That is, I'm using the query mechanism in combination with WCF RIA services. Since the life time of the object context is limited to the invocation of the query domain service operation, the context will only contain freshly queried entities and not entities that have changed (these will be present in another instance of an object context during the invocation of an update operation). So, if for this application I good gain a performance improvement by switching off change tracking I would be happy. Of course this is not an option for supporting point 2 above.

    The reason for using this query mechanism at all is because I've a huge data model where the data is scattered across a large number of tables. As a consequence, I've to deal with very complex (or better, large) queries that yield large numbers of entities. The EF queries have serious limitations here. Not only because my data model contains large inheritance hierarchies, which EF simply can't handle, but also because querying associated data is a serious performance bottleneck. My approach solves this, but I'm investigating whether the performance can be improved even more.

    Merijn

    Sunday, June 19, 2011 5:40 PM
  • Hi again!

    Well, I think your needs can't be done/improved in EF.. The framework wasn't intended to get data this way to be returned in queries against EF. I'm a bit worried that the way you're doing it can cause side-effects later on, but that's up to you to decide.

    However! If performance of queries using EF is your primary concern. Have you looked at compiled queries, or using stored procedures in EF? Both of these may help you more than having the query code outside EF.


    --Rune
    Sunday, June 19, 2011 7:37 PM
  • Hi Rune,

    Thanks again for your reply.

    You mentioned possible side-effects, do you have any particular things in mind that may give trouble? Thus far I've not  noticed any, so I would be very interested in any side-effect that I might have overseen.

    Merijn

    Monday, June 20, 2011 6:37 AM
  • Well,

    One of the things I have experienced using special approaches like this (which Self-Tracking Entities does a lot) is that I get unexpected errors in conjunction with SaveChanges and invalid states for the entities. These errors isn't always easy to find. But as long as you have control of this I think you should be ok.

    The easiest way to have control is to have your context so short lived as possible to avoid to many operations against it.


    --Rune
    Monday, June 20, 2011 7:37 AM