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.
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.
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"...
Participant
1039 Points
1327 Posts
MVP
DbContext - Object graph for type contains cycles and cannot be serialized if reference tracking...
Feb 23, 2012 03:58 PM|tugberk_ugurlu_|LINK
SPA approach is failling more and more.
here is the another issue:
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.
tweets as @tourismgeek
Member
21 Points
6 Posts
Re: DbContext - Object graph for type contains cycles and cannot be serialized if reference track...
Feb 24, 2012 06:51 AM|StijnLiesenborghs|LINK
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.
Stijn Liesenborghs
MCPD
Please "Mark As Answered" if it helped you
Member
81 Points
34 Posts
Re: DbContext - Object graph for type contains cycles and cannot be serialized if reference track...
Mar 05, 2012 10:35 AM|ColinBlair|LINK
More information: this is actually a general problem in the beta version of WebAPI and Microsoft is aware of it.
Upshot Blog
ColinBlair on Twitter
MVVM and RIA Services
Member
2 Points
6 Posts
Re: DbContext - Object graph for type contains cycles and cannot be serialized if reference track...
Mar 11, 2012 05:51 PM|larsm11|LINK
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
Member
81 Points
34 Posts
Re: DbContext - Object graph for type contains cycles and cannot be serialized if reference track...
Mar 12, 2012 03:31 PM|ColinBlair|LINK
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)
Upshot Blog
ColinBlair on Twitter
MVVM and RIA Services
Member
2 Points
6 Posts
Re: DbContext - Object graph for type contains cycles and cannot be serialized if reference track...
Mar 13, 2012 03:05 AM|larsm11|LINK
None
0 Points
11 Posts
Re: DbContext - Object graph for type contains cycles and cannot be serialized if reference track...
Mar 21, 2012 04:10 PM|Obiwan007|LINK
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"...