I have a table that should refer to the same table. But when I try to update the database schema, it throws me this error:
When i try to update the schema, PMC throws this error:
System.Data.SqlClient.SqlException (0x80131904): Introducing FOREIGN
KEY constraint 'FK_Directory_Directory_SubOfId' on table 'Directory'
may cause cycles or multiple cascade paths. Specify ON DELETE NO
ACTION or ON UPDATE NO ACTION, or modify other FOREIGN KEY
constraints.
I tried setting ON DELETE to CASCADE but nothing, still the same error. I do not know how to set NO ACTION because mapping does not offer this option.
What with this?
Entity:
public class Directory : BaseEntity
{
public int ID { get; set; }
public int? SubOfId { get; set; }
[ForeignKey("SubOfId")]
public Directory SubOf { get; set; }
public virtual ICollection<ImageDirectory> ImageDirectory { get; set; }
}
Model builder:
protected override void OnModelCreating(ModelBuilder builder)
{
base.OnModelCreating(builder);
...
builder.Entity<Directory>().HasOne(e => e.SubOf).WithOne().HasForeignKey<Directory>(a => a.SubOfId).OnDelete(DeleteBehavior.Cascade);
}
This exception isn't due to self-referencing. You get this when an entity can be deleted via multiple cascade paths. Based on the code you've provided, my best guess is that something going on with ImageDirectory and relationships in play there is actually the source of the issue.
Long and short, you need to investigate your object graph to see where removing one entity type might cause multiple cascades. Then, you'll need to shut off some of those cascades to proceed. There's not much more that can be said to help you, unfortunately, without being able to see all your entities and the relationships between them all.
Related
I have the following entity declared
public class TransactionEvent
{
[Key]
[DatabaseGenerated(DatabaseGeneratedOption.Identity)]
public Guid Id { get; set; }
public virtual List<TransactionSignInError> SignInErrors { get; set; }
}
And the context
public class TransactionAuditsDbContext : DbContext
{
public virtual DbSet<TransactionEvent> TransactionEvents { get; set; }
}
Now when I try to delete a transaction event, I want the relevant SignInError rows to be deleted as well. I realize I can do this by using cascade on delete if I had set that up in the context, too late for that now.
How can I delete successfully a transaction? I'm getting this error.
The DELETE statement conflicted with the REFERENCE constraint "FK_dbo.TransactionSignInErrors_dbo.TransactionEvents_TransactionEvent_Id". The conflict occurred in database "db", table "dbo.TransactionSignInErrors", column 'TransactionEvent_Id'
I have tried clearing the SignInErrors list before deleting, that did get rid of the above error but left NULLs in the TransactionSignInErrors table.
What you want, is "Cascade on Delete": if a TransactionEvent is deleted, then you also want that all its TransactionSignInErrors are deleted.
This works on a one-to-many relation, this does not work on a many-to-many-relation.
If you have a one-to-many relation between TransactionEvents and TransactionSignInErrors, and you followed the entity framework conventions, you will have classes like
public class TransactionEvent
{
public Guid Id { get; set; }
...
// Every TransactionEvent has zero or more TransactionSignInErrors (one-to-many)
public virtual ICollection<TransactionSignInError> SignInErrors { get; set; }
}
public class TransactionSignInError
{
public Guid Id { get; set; }
...
// Every TransactionSignInError belongs to exactly oneTransactionEvent, using foreign key
public Guid TransactionEventId {get; set;}
public virtual TransactionEvent TransactionEvent { get; set; }
}
public class TransactionAuditsDbContext : DbContext
{
public DbSet<TransactionEvent> TransactionEvents { get; set; }
public DbSet<TransactionSignInError> TransactionSignInErrors {get; set;}
}
This is all that entity framework needs to know to detect the tables, the columns in the tables and the one-to-many relation between these two tables.
In entity framework the non virtual properties represent the columns in the table, the virtual properties represent the relations between the tables (one-to-many, many-to-many, ...)
The foreign key TransactionEventId is a real column, hence it is non-virtual. TransactionEvent is not a real column, it only refers to the relation, hence it is declared virtual.
If you stick to the conventions, there is no need for attributes, nor fluent API. Only if you want non-default identifiers for tables, columns, column types or non-default behaviour for table relations, you might need attributes or fluent API.
Default behaviour is cascade on delete: if you delete a TransactionEvent, all its TransactioinSigninErrors are also deleted.
I'm not sure whether your problems arise because you have a GUID as primary key, instead of an int. If you want, you can inform entity framework about your one-to-many relation and cascade on delete in OnModelCreating:
protected override void OnModelCreating (DbModelBuilder modelBuilder)
{
// Every TransactionEvent has zero or more TransactionSignInErrors
// Every TransactionSignInError belongs to exactly one TransactionEvent
// using foreign key TransactionEventId.
// Also: cascade on delete:
modelBuilder.Entity<TransactionEvent>()
.HasMany(transactionEvent => transactionEvent.TransactionSignInErrors)
.WithRequired(transactionSignInError => transactionSignInError.TransactionEvent)
.HasForeignKey(transactionSignInError => transactionSignInError.TransactionEventId)
.WillCascadeOnDelete();
So three major changes to your code:
The DbSets in the DbContext are non-virtual
Added the table TransactionSignInErrors to your DbContext
If that is not enough for CascadeOnDelete (check this first!) add fluent API.
Small change: Use ICollection instead of IList.
Rationale: if you fetch a TransactionEvent with its TransactionSignInErrors, does TransactionEvent.SignInErrors[4] have a defined meaning? Wouldn't it be better if people have no access to methods that they don't know what they really mean?
If you want to use a cascade delete you have to include the children:
var removingRow=_context.Set<TransactionEvent>()
.Include(x=> x.SignInErrors )
.Where(x => x.Id ==id)
.FirstOrDefault();
if(removingRow != null)
{
_context.Remove(removingRow);
_context.SaveChanges();
}
Your post has the tag of entity-framework. I'm not sure how things work with Entity Framework 6 or previous versions, but with Entity Framework Core you can solve your issue like -
var tEvent = dbCtx.TransactionEvents
.Include(p=> p.SignInErrors)
.FirstOrDefault(p => p.Id == id);
foreach (var error in eventx.SignInErrors)
{
dbCtx.SignInErrors.Remove(error);
}
dbCtx.TransactionEvents.Remove(tEvent);
dbCtx.SaveChanges();
I have simple context with 3 tables.
database tables are already present but using code first approach.
Model Device.cs is -
public class Device
{
public System.Guid Id { get; set; }
public string Name{ get; set; }
}
public class sampledbContext : DbContext
{
public sampledbContext ()
: base("name=sampledbContext ")
{
}
protected override void OnModelCreating(DbModelBuilder modelBuilder)
{
modelBuilder.Conventions.Remove<PluralizingTableNameConvention>();
}
public virtual DbSet<Device> Devices { get; set; }
}
To avoid extra s I have added above line into OnModelCreating but it is giving an error -
System.InvalidOperationException: 'The model backing the 'sampledbContext' context has changed since the database was created. Consider using Code First Migrations to update the database (http://go.microsoft.com/fwlink/?LinkId=238269).'
Database was already created and I try to use code first approach here.
I have not done update-database yet.
I tried doing Enable-Migration and Update-database it creates table with name s like Devices why ? s is added ?
You've turned off auto-migrations in the line:
Database.SetInitializer<IoTSimulatordbContext>(null);
And therefore you will need to run update-database manually to update the model (you can run this via package manager console). If you have any data in your tables it is likely that the migration will fail due to the possibility of losing data, in that case you will need to either delete all data from the tables first or make a custom migration script to handle copying the data first. As this seems like a test it may be better to restart the migration project with the pluralisation off from the beginning.
You can add a DataAnnotation to describe the Schema and Table name to your Table class such as this;
[Table("Device", Schema = "MySchema")]
This will give you more control over the naming.
I have a database with a lot of tables created using code-first.
3 of the tables are
public class Machine
{
[Key]
public long ID { get; set; }
...
public virtual MachineTypeApprovalHist MachineTypeApproval { get; set; }
}
public class MachineTypeApprovalHist
{
[Key]
public long ID { get; internal set; }
...
}
public class MachineTypeApproval
{
[Key]
public long ID { get; set; }
...
}
The weird thing is that EF creates a foreign key from Machine to MachineTypeApproval (not MachineTypeApprovalHist as it should!).
I found out after long time of debugging by looking in the database table directly to see the relations between the tables. The error I got was
The UPDATE statement conflicted with the FOREIGN KEY constraint "FK_dbo.Machines_dbo.MachineTypeApprovals_MachineTypeApproval_ID". The conflict occurred in database "ATPData", table "dbo.MachineTypeApprovals", column 'ID'.
The statement has been terminated.
The error comes because it tries to use a ID from MachineTypeApprovalHist that is not in MachineTypeApprovals.
I have tried to rename the property MachineTypeApproval to TypeApproval and making a new migration, but it only renamed the table column and index.
I cannot recreate the database from scratch since I will lose my data, so what can I do to fix this?
public class DatabaseContext : DbContext
{
protected override void OnModelCreating(DbModelBuilder modelBuilder)
{
modelBuilder
.Entity<Machine>()
.HasOptional(_ => _.MachineTypeApproval)
.WithMany();
}
}
will generate these SQL statements:
ALTER TABLE [dbo].[Machines] WITH CHECK ADD CONSTRAINT [FK_dbo.Machines_dbo.MachineTypeApprovalHists_MachineTypeApproval_ID] FOREIGN KEY([MachineTypeApproval_ID])
REFERENCES [dbo].[MachineTypeApprovalHists] ([ID])
GO
ALTER TABLE [dbo].[Machines] CHECK CONSTRAINT [FK_dbo.Machines_dbo.MachineTypeApprovalHists_MachineTypeApproval_ID]
GO
I found a way to fix this, though I feel it should be easier.
The way I did it was to add another property to my Machine class to replace the first one.
public class Machine
{
[Key]
public long ID { get; set; }
...
public virtual MachineTypeApprovalHist MachineTypeApproval { get; set; }
//new property
public virtual MachineTypeApprovalHist TypeApproval {get; set;}
}
then I made a new migration which creates a new columns with foreign key to the correct table.
Now, I couldn't just remove my original property and update the database since I would lose data. So first i removed the original property MachineTypeApproval from Machine class, then adding a new migration, adding to that migrations Up method the following on the first line before any other call
Sql("update [dbo].Machines set TypeApproval_ID = MachineTypeApproval_ID ");
In this way the first migration correctly creates the new property, the second migration copies data from the old column to the new, and the second migration removes the old column, and my model and db is now correct.
I just hate that I need two migrations to do this. Also it looks like EF uses the property names BEFORE the property type to determine which table to use, which seems totally crazy to me
I am currently in the process of cleaning up a fairly large database. Part of the database has a relationship which is a one-to-zero-or-one mapping. Specifically:
User -> UserSettings
Not all users will have user settings, but a user setting cannot exist without the user. Unfortunately, the tables already exist. User has an PK ID. UserSettings has a PK ID and a column, User_Id_Fk which, at this point in time, is not a true FK (there is no relationship defined).
I'm in the process of fixing that and have done so from the DB perspective through SQL and have confirmed with tests. (Added the FK constraint. Added a unique constraint on User_Id_Fk.) This was all done on the UserSettings table. (Note: I am not using EF Migrations here. I have to manually write the SQL at this point in time.)
However, I now need to wire up an existing application to properly handle this new mapping. The application is using ASP.NET Core 1.0 and EF7. Here are (shortened) versions of the existing data models.
public class User
{
public int Id { get; set; }
public virtual UserSettings UserSettings { get; set; }
}
public class UserSettings
{
public int Id { get; set; }
[Column("User_Id_Fk")]
public int UserId { get; set; }
[ForeignKey("UserId")]
public virtual User User { get; set; }
}
I have this Fluent Mapping as well:
builder.Entity<UserSettings>()
.HasOne(us => us.User)
.WithOne(u => u.User)
.IsRequired(false);
When I go to run the application and access these items in the database, I get this error followed with a cryptic set of messages that has no information relating directly back to my application.:
ArgumentNullException: Value cannot be null.
Parameter name: navigation
Microsoft.Data.Entity.Utilities.Check.NotNull[T] (Microsoft.Data.Entity.Utilities.T value, System.String parameterName) <0x10d28a650 + 0x00081> in <filename unknown>, line 0
After doing research, someone had mentioned that the ID of the UserSettings class must be the same as the foreign key, like so:
public class UserSettings
{
[Key, ForeignKey("User")]
public int Id { get; set; }
public virtual User User { get; set; }
}
I don't really have this as an option as the DB is being used for other applications I have no control over at this point. So, am I stuck here? Will I just have to maintain a 1:many mapping (which could happen now, though it hasn't) and not have proper constraints for a 1:0..1 mapping?
Update
Looking at octavioccl's answer below, I tried it out without any success. However, I then removed User from the mapping in UserSettings (but I left UserId). Everything appeared to work as far as I can tell. I'm really confused what is going on here, however, and if this is even the right answer, or if I'm just getting lucky.
Remove the data annotations and try with these configurations:
builder.Entity<UserSettings>()
.Property(b => b.UserId)
.HasColumnName("User_Id_Fk");
builder.Entity<User>()
.HasOne(us => us.UserSettings)
.WithOne(u => u.User)
.HasForeignKey<UserSettings>(b => b.UserId);
From EF Core documentation:
When configuring the foreign key you need to specify the dependent
entity type - notice the generic parameter provided to HasForeignKey
in the listing above. In a one-to-many relationship it is clear that
the entity with the reference navigation is the dependent and the one
with the collection is the principal. But this is not so in a
one-to-one relationship - hence the need to explicitly define it.
The example that is presented in the quoted link (Blog-BlogImage) is pretty much the same of what are you trying to achieve.
If the solution that I show above doesn't work, then you should check if User_Id_Fk column allows null. If that is the case, change the FK property type to int?:
public class UserSettings
{
public int Id { get; set; }
public int? UserId { get; set; }
public virtual User User { get; set; }
}
I'm getting the following error message while trying to delete an item from the db:
The operation failed: The relationship could not be changed because one or more of the foreign-key properties is non-nullable. When a change is made to a relationship, the related foreign-key property is set to a null value. If the foreign-key does not support null values, a new relationship must be defined, the foreign-key property must be assigned another non-null value, or the unrelated object must be deleted.
I've read many topics about this issue, but none of them seem to help (or maybe i didn't understand them very well).
my models are:
public class ARDOperation
{
[Key]
public int ARD { get; set; }
[Required]
public virtual ICollection<Act> Actions { get; set; }
public ARDOperation()
{
this.Actions = new List<Act>();
}
}
public class Act
{
[Key]
[DatabaseGenerated(DatabaseGeneratedOption.Identity)]
public int ARDID { get; set; }
public int ARDOperationId { get; set; }
[ForeignKey("ARDOperationId")]
public virtual ARDOperation ARDOperation { get; set; }
public string Data { get; set; }
[EnumDataType(typeof(ARDState))]
public ARDState State { get; set; }
}
I Also defined a fluent API:
public class ARDOperationDBContext : DbContext
{
public DbSet<ARDOperation> ARDOperation { get; set; }
//public DbSet<Act> Act { get; set; }
protected override void OnModelCreating(DbModelBuilder modelBuilder)
{
modelBuilder.Entity<Act>()
.HasRequired(t => t.ARDOperation)
.WithMany(t => t.Actions)
.HasForeignKey(d => d.ARDOperationId)
.WillCascadeOnDelete(true);
//modelBuilder.Entity<ARDOperation>()
}
The method in controller:
internal void RemoveAction(int ARDID)
{
var op = ARDOperationDB.ARDOperation.Find(ARDID);
if (op != null)
{
//will not remove the "idle" action
if (op.Actions.Count > 1)
{
Act act = op.Actions.ElementAt(1);
op.Actions.Remove(act);
//ARDOperationDB.Entry(op).State = EntityState.Modified;
ARDOperationDB.SaveChanges();
}
}
}
I've tried to define the "ARDOperationId" property as nullable (int?) using code-first approach and i'm not getting any errors this way, but the child's data still remain in the DB.
I think that i'm missing something related to the access to the Act model.
Will appreciate any help,
Yuval.
Take a look at [this answer][1] from an EF guru about the remove method.
EntityCollection.Remove(childEntity) marks the relationship between
parent and childEntity as Deleted. If the childEntity itself is
deleted from the database and what exactly happens when you call
SaveChanges depends on the kind of relationship between the two:
If the relationship is optional, i.e. the foreign key that refers from
the child to the parent in the database allows NULL values, this
foreign will be set to null and if you call SaveChanges this NULL
value for the childEntity will be written to the database (i.e. the
relationship between the two is removed). This happens with a SQL
UPDATE statement. No DELETE statement occurs.
If the relationship is required (the FK doesn't allow NULL values) and
the relationship is not identifying (which means that the foreign key
is not part of the child's (composite) primary key) you have to either
add the child to another parent or you have to explicitly delete the
child (with DeleteObject then). If you don't do any of these a
referential constraint is violated and EF will throw an exception when
you call SaveChanges - the infamous "The relationship could not be
changed because one or more of the foreign-key properties is
non-nullable" exception or similar.
If the relationship is identifying (it's necessarily required then
because any part of the primary key cannot be NULL) EF will mark the
childEntity as Deleted as well. If you call SaveChanges a SQL DELETE
statement will be sent to the database. If no other referential
constraints in the database are violated the entity will be deleted,
otherwise an exception is thrown.
[1]:
Entity Framework .Remove() vs. .DeleteObject()
So i read a bunch of articles on this subject. Chris's response here was really good and helpful for my understanding: Link
But what really helped me was the small code example here: Solution.
The "[Key, ForeignKey("Order"), Column(Order = 1)]" part really did the trick.
Many Thanks!