Sign Up

Sign Up to our social questions and Answers Engine to ask questions, answer people’s questions, and connect with other people.

Have an account? Sign In

Have an account? Sign In Now

Sign In

Login to our social questions & Answers Engine to ask questions answer people’s questions & connect with other people.

Sign Up Here

Forgot Password?

Don't have account, Sign Up Here

Forgot Password

Lost your password? Please enter your email address. You will receive a link and will create a new password via email.

Have an account? Sign In Now

You must login to ask a question.

Forgot Password?

Need An Account, Sign Up Here

Please briefly explain why you feel this question should be reported.

Please briefly explain why you feel this answer should be reported.

Please briefly explain why you feel this user should be reported.

Sign InSign Up

The Archive Base

The Archive Base Logo The Archive Base Logo

The Archive Base Navigation

  • SEARCH
  • Home
  • About Us
  • Blog
  • Contact Us
Search
Ask A Question

Mobile menu

Close
Ask a Question
  • Home
  • Add group
  • Groups page
  • Feed
  • User Profile
  • Communities
  • Questions
    • New Questions
    • Trending Questions
    • Must read Questions
    • Hot Questions
  • Polls
  • Tags
  • Badges
  • Buy Points
  • Users
  • Help
  • Buy Theme
  • SEARCH
Home/ Questions/Q 8795663
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Editorial Team
Asked: June 13, 20262026-06-13T23:26:16+00:00 2026-06-13T23:26:16+00:00

I understand why EF does not allow cyclical references in the PK/FK relationships. I

  • 0

I understand why EF does not allow “cyclical references” in the PK/FK relationships. I am looking for advice on how to alter my model to make the following scenario work.

Scenario

Three entities: Employee, Agency, WorkRecord. Their purpose is to log Employee time spent doing work. Employee then contains reference to the Agency he/she is employed by, and his/her WorkRecord contain reference to the Agency the work was done for.

public class Employee
{
    [Key]
    public int Id { get; set; }

    public string Name { get; set; }

    public int AgencyId { get; set; }
    public virtual Agency Agency { get; set; }

    public virtual IEnumerable<WorkRecord> WorkRecords { get; set; }
}

public class Agency
{
    [Key]
    public int Id { get; set; } 
}

public class WorkRecord
{
    [Key]
    public int Id { get; set; } 

    public int Hours { get; set; } 

    public int AgencyId { get; set; } 
    public virtual Agency Agency { get; set; } 

    public int EmployeeId { get; set; }
    public virtual Employee { get; set; }
}

Like this, it bitches: FK_dbo.WorkRecords_dbo.Employees_EmployeeId causes a cyclical reference.

Experiments

My first thought was because of the bi-directional virtual properties, so I decided to designate one of the two a top-level entity with a 1-way relationship:

First, I designated WorkRecord as a top-level entity and remove the virtual WorkRecords reference reference from the Employee entity… the same message is produced.

Second, I made Employee the top-level entity, leaving its virtual WorkRecords collection, and removing the virtual Employee reference property from the WorkRecord entity… works fine but does not achieve my goal.

After more investigation, I find it is the Agency virtual reference property on both entities that causes the circular reference. If one entity removes this, the Employee/WorkRecord entity relationships work in all directions.

Question:

So, clear as i can ask – how can I express this business model, using WorkRecord as my top-level entity, without making EF5 upset?

  • 1 1 Answer
  • 0 Views
  • 0 Followers
  • 0
Share
  • Facebook
  • Report

Leave an answer
Cancel reply

You must login to add an answer.

Forgot Password?

Need An Account, Sign Up Here

1 Answer

  • Voted
  • Oldest
  • Recent
  • Random
  1. Editorial Team
    Editorial Team
    2026-06-13T23:26:17+00:00Added an answer on June 13, 2026 at 11:26 pm

    It sounds like you just want to get EF off your back, but I think it’s actually expressing a valid problem in the coupling of your data. If you bind AgencyId to both WorkRecord and Employee then updating the AgencyId on WorkRecord, for example, will cascade to Employee. Which will then cascade to WorkRecord etc. Hence “circular reference”. You really should designate which of those data objects will “own” the relationship to Agency.

    Personally, I suspect that the most natural binding is to reference the Agency from the WorkRecord. I can see a scenario where an Employee might move from one agency to another but it’d be much harder for a WorkRecord to move from one Agency to another. It’s also the case that an Employee without a WorkRecord can’t really be termed much of an Employee, really. If you determine this to be the case, then I’d remove the Agency reference from Employee. If you need to get to the Agency from the Employee then you probably should go through a WorkRecord anyway.

    All of that is merely conceptual, however. I suspect that if you make it possible for AgencyId to be null on the Employee that EF won’t complain any longer (and you might want it optional on both). That should make it valid for an Employee to be updated without requiring a circular update with WorkRecord. I’d have to test that to verify, but I suspect it’d hold true.

    public class Employee
    {
        [Key]
        public int Id { get; set; }
    
        public string Name { get; set; }
    
        public int? AgencyId { get; set; }
        public virtual Agency Agency { get; set; }
    
        public virtual IEnumerable<WorkRecord> WorkRecords { get; set; }
    }
    
    • 0
    • Reply
    • Share
      Share
      • Share on Facebook
      • Share on Twitter
      • Share on LinkedIn
      • Share on WhatsApp
      • Report

Sidebar

Related Questions

I simply could not understand why the following code does not work. What could
I'm trying to understand why the following test does not fail. In this simplified
I'm newbie in Python. I can't understand why this code does not work: reOptions
Why does this not work? Do I not understand delegate covariance correctly? public delegate
As far as I understand heroku does not allow to store uploaded files for
I do not understand why the compiler does not allow this: Callable callable =
I understand that shared memory on GPU does not persist across different kernels. However,
I do not understand what is wrong with this query? Query tool does not
As I understand it, DWScript does not compile scripts into an intermediary bytecode. However,
Consider the code below. I don't understand why my GCC compiler does not try

Explore

  • Home
  • Add group
  • Groups page
  • Communities
  • Questions
    • New Questions
    • Trending Questions
    • Must read Questions
    • Hot Questions
  • Polls
  • Tags
  • Badges
  • Users
  • Help
  • SEARCH

Footer

© 2021 The Archive Base. All Rights Reserved
With Love by The Archive Base

Insert/edit link

Enter the destination URL

Or link to existing content

    No search term specified. Showing recent items. Search or use up and down arrow keys to select an item.