Commented Feature: Consider disabling validation of [Required] on navigation properties [1571]

The fact that we validate [Required] on nav props can be annoying. The following details are from a bug report where this behavior was not expected...

So I have the following Entities :

[Table("UserTbl")]
public abstract class User
{
[Key]
[DatabaseGeneratedAttribute(DatabaseGeneratedOption.Identity)]
public int UserId { get; set; }
[Required]
public string Username { get; set; }
[Required]
public DateTime CreatedDate { get; set; }
[Required]
public virtual UserPassword Password { get; set; }
[Required]
public string RegistrationNr { get; set; }
[Required]
public string ContactPerson { get; set; }
[Required]
public string Email { get; set; }
[Required]
public string PhoneNr { get; set; }

[Required]
public bool HasBeenApproved { get; set; }

public DateTime? InactivationDate { get; set; }
}


[Table("UserPasswordTbl")]
public class UserPassword
{
[Required]
[Key]
[ForeignKey("User")]
public int UserId { get; set; }
[Required]
public User User { get; set; }
[Required]
public string Password { get; set; }
[Required]
public string Salt { get; set; }
public DateTime? PasswordChangedDate { get; set; }
public DateTime? LastPasswordFailureDate { get; set; }
public int PasswordFailuresSinceLastSuccess { get; set; }
}


Just a User object which has a property of a password object which is required for it to work.

then when the following method is called:

public string ActivateUser(string encryptedUsername)
{
string decryptedUsername = CryptographyTools.DecryptText(encryptedUsername);
User user = _userRepository.GetUser(decryptedUsername);
if (user != null)
{
user.HasBeenApproved = true;
_userRepository.SaveChanges();
}
return decryptedUsername;
}

a DbEntityValidationException is thrown. The EntityValidationErrors property of the exception suggests that the users Password property is not valid. However(!!), if I put a breakpoint somewhere after retrieving the user object from the repository and before the call to SaveChanges, this exception is not thrown and the entity is successfully updated in the database.

I had to fix this bug by removing the Required attribute from the Password property of the user entity.

I think EF is failing to load my object properly before a call is made to SaveChanges, maybe there is some weird yield return implementation.

//Siavash
Comments: For anyone looking at the possibility of changing the behavior in the future: Because the object graph is a virtualized version of what exist in the database, a null nav-prop can mean one of two things: a. The entity is not associated with another entity b. The association hasn't been loaded The only way to know for sure would be to query the database, but we don't want to be triggering lazy loading or otherwise causing database roundtrips as part of validation (AFAIR, we turn lazy loading off during validation). One way to avoid false validation errors would be to test for the value of IsLoaded before we validate this attribute. If IsLoaded is true and the nav-prop is null, then we know that we are in the presence of (a) and it is ok for the validation to cause an error. If however IsLoaded is false, we can't assume that the relationship doesn't exist in the database, and we could then ignore the attribute.