Materializing and attaching object graph is causing lazy-load SQL query for the original object

Thread is closed for posting
1 posts, 0 answers
  1. Andrew
    Andrew avatar
    9 posts
    Member since:
    Mar 2012

    Posted 18 Nov 2016 Link to this post

    My goal is to be able to attach an instance of a persistent object to a context which did not derive from an existing context or a SQL query (using IDbConnection).  

    For instance:

    //-------------------------------
    //C# Class
    public class Widget
    {
        public int Id { get; set; }
        public int Name { get; set; }
    }
    //-------------------------------
    //SQL Table
    TBWIDGETS
    ID INT PRIMARY KEY IDENTITY
    NAME VARCHAR(100)
    //-------------------------------
    //C# Example
    using (DbContext context = new DbContext())
    {
        Widget detached = new Widget();
        detached.Id = 1;
        detached.Name = "test";
        
        //Causes a SQL query in the format:
        //SELECT NAME FROM TBWIDGETS WHERE ID = 1
        Widget attached = context.AttachCopy(detached);
    }

    I have attempted several different approaches to solve this problem include:

    1. The above approach; utilizing the AttachCopy<T>() method

    2. Using the context.Translate functionality against a DataTable / DataTableReader; derived from:

    http://docs.telerik.com/data-access/developers-guide/low-level-ado-api/translating-dbdatareader/dev-guide-adoapi-translate-dbdatareader-persistent-types

    Note: When I used the straight SQL query example in the above line, the materialization did not cause an additional SQL query.

    3. Using the serialization / deserialization as documented in:

    http://www.telerik.com/help/openaccess-classic/openaccess-tasks-working-with-objects-serialize-deserialize.html

    While a single SQL query to "rebuild" the persistent class from the database is not too concerning, performing this operation for a collection will cause significant overhead.

     

    Note: If the object is initially attached to context, detached and that detached instance is attached to another instance of the same context; this does not cause an additional SQL query.  Although in my scenario, I can not rely on this approach.

     

    For reference, I am using version 2014.2.711.1 of the Telerik Data Access library.

     

    Thanks

Back to Top