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

One-to-one relationship with navigation properties on both ends throws StackOverflowException #3806

Closed
jparish9 opened this issue Nov 19, 2015 · 4 comments
Assignees
Labels
closed-fixed The issue has been fixed and is/will be included in the release indicated by the issue milestone. type-bug
Milestone

Comments

@jparish9
Copy link

Windows 10, VS 2015, IIS Express, SQL Server Express 2014, EF 7.0.0-rc1-final, ASP.NET 6.0.0-rc1-final

After upgrading to RC1, I am seeing a StackOverflowException with the following one-to-one relationship setup. This setup was working fine in beta8.

Models:

    public class Blog
    {
        public int BlogId { get; set; }

        public string Title { get; set; }

        public virtual BlogMetadata BlogMetadata { get; set; }
    }
    public class BlogMetadata
    {
        [Key, ForeignKey("Blog")]
        public int BlogId { get; set; }

        public string Metadata { get; set; }

        public virtual Blog Blog { get; set; }
    }

FK setup:

   modelBuilder.Entity<Blog>().HasOne(b => b.BlogMetadata).WithOne();

The FK setup line throws StackOverflowException after upgrading to RC1 (but not in beta8).

The StackOverflowException is not thrown if I remove the navigation property
public virtual Blog Blog {get; set;} from BlogMetadata.

@smitpatel
Copy link
Contributor

@jparish9 - Thank you for reporting this bug. It does appear in RC1 bits due to relationship building convention calling each other while trying to create 2 relationships.
There will be 2 relationships. One is configured explicitly and the other one will use Blog navigation property and BlogId foreign key property (FKAttribute).
Though the issue has been fixed in some other changes after RC1.
Work-around would be to configure the other relationship explicitly.
If you add this code in OnModelCreating then it will work

modelBuilder.Entity<BlogMetadata>().HasOne(e => e.Blog).WithOne();
modelBuilder.Entity<Blog>().HasOne(b => b.BlogMetadata).WithOne();

@jparish9
Copy link
Author

@smitpatel Thank you for the workaround, it seems to work and is good enough for now.

Models w/annotations:

    public class Blog
    {
        public int BlogId { get; set; }

        public string Title { get; set; }

        [ForeignKey("BlogId")]
        public virtual BlogMetadata BlogMetadata { get; set; }
    }
public class BlogMetadata
    {
        [Key]
        public int BlogId { get; set; }

        public string Metadata { get; set; }

        public virtual Blog Blog { get; set; }
    }

FK configuration:

            modelBuilder.Entity<BlogMetadata>().HasOne(e => e.Blog).WithOne();
            modelBuilder.Entity<Blog>().HasOne(b => b.BlogMetadata).WithOne();

Now the 1-1 relationship is correctly configured. (Without the [ForeignKey("BlogId")] annotation, it does not throw StackOverflowException, but an extra column BlogMetadataBlogId is created in Blog.)

Thank you for the quick response!

@rowanmiller
Copy link
Contributor

If you don't want two separate relationships, then this is the config you want:

modelBuilder.Entity<Blog>()
    .HasOne(b => b.BlogMetadata)
    .WithOne(m => m.Blog)
    .HasForeignKey<BlogMetadata>(m => m.BlogId);

@rowanmiller rowanmiller added this to the 7.0.0 milestone Nov 20, 2015
@rowanmiller rowanmiller modified the milestones: 7.0.0-rc2, 7.0.0 Dec 7, 2015
@smitpatel
Copy link
Contributor

This works fine in latest codebase. Slightly different variation of this is covered by #3832

@ajcvickers ajcvickers added the closed-fixed The issue has been fixed and is/will be included in the release indicated by the issue milestone. label Oct 15, 2022
@ajcvickers ajcvickers modified the milestones: 1.0.0-rc2, 1.0.0 Oct 15, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
closed-fixed The issue has been fixed and is/will be included in the release indicated by the issue milestone. type-bug
Projects
None yet
Development

No branches or pull requests

4 participants