How does many to many work with onDelete cascade with Postgres?
If I have an array of entities A and B connected with M2M
I erase an entity of B
Other entities are still connected to A (It wasn't the last entity)
Will it erase A?
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
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'.
I have a codefirst EF-4.1 based program. The user gets a context and can modify some properties. When the user is done, I do a quick
ChangeTracker.Entries().Any(e => e.State != EntityState.Unchanged);
to determine if a SaveChanges() is required or not. If I do a 'SaveChanges()' call, the changes that have made are persisted to the database.
This works for some properties, and doesn't work for others. Specifically it seems to work with simple types (floats), and with collection hierarchies(ObservableCollections).
Am I doing something wrong?
Yes this is a problem. Some relations are not tracked by DbChangeTracker. There is difference between Independent association and Foreign key association. Changes to relation are tracked in case of:
One-to-one relation which is always Foreign key association in EFv4+
One-to-many relation with Foreign key association - you should set up foreign key property
Changes to relation are not tracked in case of:
One-to-many relation with Independent association
Many-to-many relation which is always Independent association
Not tracked for Independent association is not correct naming. These changes are tracked but DbChangeTracker does not expose access to these changes! You must convert DbContext to ObjectContext and use ObjectStateManager to get access to ObjectStateEntries representing independent associations.
In this case the easiest thing is simply call SaveChanges always. It will not execute any DB commands if no data need to be saved.
Consider that i have two entities with following relationship:
Entity A <-->> Entity B (one-to-many and inverse)
Now consider that i have another entity Entity C that contains all the attributes of Entity B and some others, with following relationship:
Entity A <-->> Entity C (one-to-many and inverse)
Now i can improve the architecture by making Entity B the parent of Entity C.
Entity B
^
|
Entity C
Now, my question is, will the attribute(s) AS WELL AS the relationship(s) be inherited by Entity C? Meaning, do i still need to keep the following relationship (separately)?:
Entity A <-->> Entity C
Also, i couldn't find a good example for entity inheritance in Apple documentation for Core Data. Does anyone know of an online resource that explains this, with example (preferably)?
Yes, attributes and relationships and everything else will be inherited. Be careful though, child entities like that will share the same table in sqlite with the parent entity. So if you have C inheriting from B, then a table will be created in sqlite that has the properties for both B and C which the obvious voids in the table. This is not too much of an issue with a simple inheritance like this but if you decide to get "creative" you can end up with your entire model in one table.
Now, my question is, will the
attribute(s) AS WELL AS the
relationship(s) be inherited by Entity
C? Meaning, do i still need to keep
the following relationship
(separately)?:
Yes all attributes and relationships are inherited.
Only little documentation is available at ADC
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.