I have the following data model and i want to break the many-to-many relationship between EntityA and EntityB. I'm doing this by removing EntityC object that connects both of them. I found that EntityA still have a relationship with EntityB although I saved the managed object context, I can see the changes take affect after EntityA records are re-fetched from database.
Is there something I'm missing? Thanks in advance,Sarah
I agree with the comment from Barry, from your description it sounds like you are using more than one NSManagedObjectContext and that will definitely cause an issue.
Is this a multi-threaded application?
Did you base this off of one of the Apple examples?
update
Referental integrity is the mostly likely cause of this issue. When you delete A, the relationship to C, from C's point of view may not be cleared immediately because Core Data does that kind of clean up either at the end of the run loop or at the next save. This means if you are peeking at the value before either of those occur, the relationship may be there. Are you look at the relationship immediately or is it hanging around a while late, i.e. after a save?
update
In your original question you stated that after the save EntityA still has a relationship to EntityB. Is this a typo? According to your model EntityA and EntityB do not have a direct relationship. Can you clarify?
or perhaps show the code where you delete EntityC and where you see EntityA having a relationship with EntityB.
Related
I'm a bit confused about this naming convention.
What is the difference between them and are target/source interchangeable with owning/not owning?
One thing in particular is hard to understand:
"The main difference between a OneToOne and a ManyToOne relationship in JPA is that a ManyToOne always contains a foreign key from the source object's table to the target object's table, where as a OneToOne relationship the foreign key may either be in the source object's table or the target object's table"
JPA wikibooks
I can't imagine such situation in uni one-to-one
Differences between them are a little confusing. You should practice a lot to understand very well.
At first, you should understand some terminology:
Role : In every relationship there are two entities that are related to one another, and each entity is said to play a role in the relationship.
Direction : Relationships can be unidirectional or bidirectional. For e.g.. a Person has an address is normally unidirectional whereas Employee working on a project is normally bidirectional. We will look at how to identify and define directionality while coming up with a Data Model.
In order to have relationships at all, there has to be a way to create, remove, and maintain them. The basic way this is done is by an entity having a relationship attribute that refers to its related entity in a way that identifies it as playing the other role of the relationship. It is often the case that the other entity, in turn, has an attribute that points back to the original entity. When each entity points to the other, the relationship is bidirectional. If only one entity has a pointer to the other, the relationship is said to be unidirectional. A relationship from an Employee to the Project that they work on would be bidirectional. The Employee should know its Project, and the Project should point to the Employee working on it. A UML model of this relationship is shown here. The arrows going in both directions indicate the bidirectionality of the relationship (Form this book >> Pro JPA 2)
Then dive into this link (archived from the original)
I'd like to comment only the links, but I need 50 reputation
We have recently decided to use EF6 code first in one of our projects so I am undergoing a paradigm change. I really enjoy EF but some things are so different they seem wrong.
I just want to run a scenario by the community to see if I am thinking correctly.
We have an entity that has child entities of the same type.
If I was saving a child normally I would just save a new entity with the parent id set to the id of the parent. In the entity world they are connected through a navigation property of the same type as follows:
public class SomeType
{
public id;
....
public virtual IList<SomeType> Children
}
Obviously the standard approach doesn't work here since I am not manipulating DB foreign keys manually.
It seems the "Entity Way" would be to first use DBCcontext and linq to select the parent, then add the new entity to the Children list and save the whole thing.
Which is fine and logical - but it just seems a little inefficient to do a select every time i am doing a save.
Am I really missing something here do I just need to get used to a different way of thinking here?
Thank you!
If I'm getting your problem right, then you can and should save the child as a simple Sometype with a parentId, just as you would without using the entity framework. The automagic of the EF shouldn't cause a problem for you here, and you would not be breaking any best practices.
Essentially: If the parent entity is already loaded into context, it's usually best to add the new entity to the collection of navigation properties (Children in your case, but any foreign key). If the parent is not loaded and you know it's id, populate the foreign key field and save it just as you always did.
I've two entities a and b and an m2m association between them. Entities a and b are loaded in my DbContext, while the m2m associaiton is not. Now, in my program I know the primary keys of a and b and I need to remove the m2m association.
Of course, I could -reload a from the database and include its m2m association. However, this requires an additional round trip to the data base to get the entities from the database.
I could also first detach a from the DbContext, then add b to its BSet, then attach a again and then call remove something like:
context.Entry(a).State = EntityState.Detached;
a.Bset.Add(b)
context.Set(typeof(A)).Attach(a);
a.BSet.Remove(b)
However, by detaching a from its context and then attaching it, I loose the changes that have been made to a. Consequently, calling SaveChanges() may not persist all changes of a to the database.
My question is: how can I remove the m2m association between a and b without an additional round trip to the database and without loosing any changes made to a or b?
[edit: What I'm looking for is a method a.BSet.Attach that would enable me to attach an existing m2m association between a en b]
I'm using the latest version of Entity Framework and I'm using DbContext.
Any help is welcome.
PS. this is a repost of http://social.msdn.microsoft.com/Forums/en-US/adodotnetentityframework/thread/5edea208-24cc-497b-8592-9cb025d558e4/
Thanks in advance,
Merijn
I was in the same problem a few days ago and the solution I came up is:
context.Entry(a).State = EntityState.Detached;
a.BSet.Add(b);
context.Entry(a).State = EntityState.Modified;
a.BSet.Remove(b);
with that code you should be removing the m2m association and preserving all the changes to the database.
EDIT:
I just realized that we have made almost the same code, just reattach your entity changing its state to 'Modified'.
In model first, when we create a one to many relationship between two entities, there will be a FK auto-created in many end, when we do in code first, do we need to add a FK property in the many end entity? Why?
Thx in advance!
I once had some problems with relationships. It turned out I had to add the FK property otherwise EF couldn't see the relationship and track the changes, see my old question: How to update related entities in Entity Framework
You don't need to add it. If you don't add it EF will generate it in database in the same way as it did it in model first. The question Why? refers to difference between foreign key and independent associations.
The following code:
order.Orderlines.Remove(orderline)
Means not only to remove relationship between Order and Orderline but also to remove orderline from persistence permanently. Many slave entities have this situation.
As I know, in entity framework have to write extra code:
context.DeleteObject(orderline);
Or,
context.Orderlines.DeleteObject(orderline);
So, the remove rule can't be encapsulated entirely in order itself.
Any better choice for one line deletion in entity framework?
It's not entirely clear to me what you are asking, but here is a very complete description of various scenarios for deleting related entities, which will hopefully answer your question.