locked
DbContext - Object graph for type contains cycles and cannot be serialized if reference tracking is disabled RRS feed

  • Question

  • User-706647060 posted

    SPA approach is failling more and more.

    here is the another issue: 

    Object graph for type 'ListItCheckIt.Data.DataAccess.SqlServer.Category' contains cycles and cannot be serialized if reference tracking is disabled.

    my entities have links between parents and children items in both directions. Here is my DbContext:

        public class ListItCheckItContext : DbContext {
    
            public ListItCheckItContext() {
    
                Database.SetInitializer<ListItCheckItContext>(new DropCreateIfChangeInitializer());
            }
    
            public DbSet<Category> Categories { get; set; }
            public DbSet<Item> Items { get; set; }
    
            public class DropCreateIfChangeInitializer : DropCreateDatabaseIfModelChanges<ListItCheckItContext> {
    
                protected override void Seed(ListItCheckItContext context) {
    
                    context.Categories.Add(new Category { 
                        CategoryName = "Work",
                        Items = new List<Item>() { 
                            new Item { Task = "Check this!", IsCompleted = false }
                        }
                    });
    
                    context.SaveChanges();
    
                    base.Seed(context);
                }
            }
        }


    When I try to get the values like below:

            public IQueryable<Item> GetItems() {
    
                return DbContext.Items.Include("Category");
            }


    It loops through endlessly and shuts down the web server at the end and throw and error. this is my dummy implementation and I can create references in one direction (from parent to child). That's fine.

    But I have some existing DbContext implementations and they all have links between parents and children items in both directions.

    Thursday, February 23, 2012 3:58 PM

Answers

  • User1916654149 posted

    Hi,

    I was facing the same problem when I was playing around with the Single Application Template.

    I have resolved this issue by using a private setter on the collection property. In your case on the Items property.

    public virtual ICollection<Item> Items {get; private set;}

    Don't know if this is possible for your case.

    • Marked as answer by Anonymous Thursday, October 7, 2021 12:00 AM
    Friday, February 24, 2012 6:51 AM

All replies

  • User1916654149 posted

    Hi,

    I was facing the same problem when I was playing around with the Single Application Template.

    I have resolved this issue by using a private setter on the collection property. In your case on the Items property.

    public virtual ICollection<Item> Items {get; private set;}

    Don't know if this is possible for your case.

    • Marked as answer by Anonymous Thursday, October 7, 2021 12:00 AM
    Friday, February 24, 2012 6:51 AM
  • User-477222212 posted

    More information: this is actually a general problem in the beta version of WebAPI and Microsoft is aware of it.

    Monday, March 5, 2012 10:35 AM
  • User-2061186473 posted

    Thanks for clarifying Colin. Do you know of any link to where this issue is being tracked.

    Stijn - adding private to the setter worked like a charm.

    LM

    Sunday, March 11, 2012 5:51 PM
  • User-477222212 posted

    When WebAPI moves to production they are switching the JSON serializer to JSON.NET which, among many other improvements, knows how to handle this issue.

    http://www.hanselman.com/blog/OnTheNightmareThatIsJSONDatesPlusJSONNETAndASPNETWebAPI.aspx

    (Sorry for the delay, had to find a public Microsoft statement that they are changing to JSON.net)

    Monday, March 12, 2012 3:31 PM
  • User-2061186473 posted
    Thanks Colin. That's good news. LarsM
    Tuesday, March 13, 2012 3:05 AM
  • User1438702617 posted

    I tried to exchange the serialisation like Hanselman blogged. So far the cyclic reference was not resolved.

    I manually set the backreference in the child entity to NULL. That worked like a charm. I do not need that data in the view anyways.

    BUT: if you try to send back changed data its failing completely with the remark that it could not submit the backreference in the child...

    We are in so heavy need now to get our own DTO objects up and running and have more control on what data is really sent to the client and submitted to the DB.

    Btw - this would help to prevent POST manipulations too. If you do not get the "IsAdmin" property to the client it could not set it to "True"...

     

    Wednesday, March 21, 2012 4:10 PM