I'm experiencing issues deleting parent objects in an object graph using breeze, when there are complex graphs of children involved. Every time I try to delete a parent, I get foreign key conflicts, even if there is only one simple child. Any advice? Before I post code here, I'd like to understand existing issues I should be aware of. My breeze controller is working with EF6.
The reason you are getting the error is because you have a foreign key constraint. In your code-first DBContext you establish a relationship between a parent and a child and you probably aren't telling EF what to do in case of deletion.
You can either enable the cascading deletes, or set the rules however you want using Fluent API. Check this answer for more details -
Cascade Delete Rule in EF 4.1 Code First when using Shared Primary Key Association
Related
I've seen this post, my problem is quite the opposite, EF is treating the entities as two separate 1 to many relation, so the User have many UserInRole, and the Role also have many UserInRole entities, shouldn't EF automatically hide the UserInRole table and give a navigation property Roles for User and Users for Role. What I want is actually this:
Deleting the entity from the edmx and updating changes fixed it, apparently when I updated the model from the database in the edmx designer it kept columns that I removed from the database maybe because it was referenced somewhere else in the project, anyway I deleted the entire entity manually and updated the changes / re-added the missing tables and it did the trick.
I'm working on a project already started by several developers before me. One thing in particular bothers me is that they have single entity split in two databases.
Entity is called Tracker.
First database is called ConfigBase, and it has table named Trackers that has TrackerId along with it's attributes.
Second database is called StoreBase, and it also has table named Trackers, whose elements have matching TrackerId as it is in the first base.
Moreover, to have things even more complicated, when you access specific tracker in ConfigBase, you gain SQL server name and credentials that allow you to access it in StoreBase.
Now all this isn't too much complicated if you use plain old ADO.NET. But as my task is to raise entire solution to newest EF 4.3.1, I'm having troubles maintaining consistency of my entity. Half of things related to Tracker entity are in ConfigBase and the other half in StoreBase, and usually I have to get both to get some result.
Is there any solution to this that does not involve virtual merge on database level. I'm looking for a solution that can be done with Code First modelling.
Thanks in advance!
No there is no solution provided out of the box because EF itself is even not able to use more than one database per context. So you will either merge your databases or you will access each database separately (with separate Tracker entity per database) and merge data somehow in your application.
I saw this Post by ADO.Net team which looks very promising until I started using it in my application. I have EF 4.0 model with close to 100 self tracking entities. After including the iterator in my project, any of the extension methods "StartTrackingAll" or "StopTrackingAll" would take 5sec to finish. Has anyone ran into same issue or anyone knows of any better option.
Are your entities in relation? In that case you don't need to use StartTrackingAll because StartTracking itself starts tracking for whole object graph:
The StartTracking method instructs the
change tracker on the entity to start
recording any changes applied to the
entity. This includes changes to
scalar properties, collections, and
references to other entities. The
self-tracking entities start tracking
automatically when they are
deserialized into the client through
the Windows Communication Foundation
(WCF). The tracking is also turned on
for newly created entities in the
following scenarios:
* A relationship is created between the new entity and an entity that is already tracking changes.
* The MarkAs[State] or AcceptChanges method is called on an entity.
If you are not using related entities it sounds strange that you need to track 100 entities in the same time. Also if entities don't have relations it is perhaps not needed to track them at all.
I saw this comment on MSDN (link and link):
"Note that Independent Associations should often be avoided since things like
N-Tier and concurrency becomes more difficult."
I'm new to EF4 and I'm building an n-Tier web app. This sounds like an important pitfall. Can someone explain to me what this means?
I think it's personal preference. Originally, EF was created to only use indep. associations and aligned with a more classic ERM approach. However, most of us devs are so dependent on FKs that it made life very complex. So MS gave us FKs in EF4 which meant not only having the FK as a property in the dependent entity but the relationships are defined through constraints in the conceptual model rather than buried in the mappings. There are still a few relationships that you can only define with an indep association: many to many and unique foreign keys. Note that if you are planning to use RIA Services (doesn't sound like it) that RIA only recognizes FK associations.
So if you prefer to leverage the independent associations you still absolutely can use them in EF4. They are totally supported. But as James suggests, there are a few more traps to be aware of...things that you'll need to do more explicitly because of the way EF works with graphs especially. Or that case where you do just want that FK , e.g., you have the ID of a customer but you don't h ave the instance. You could create an order but without that nice CustomerID FK property, you have to do some extra juggling to get that CustomerID in there.
hth
If you're new to EF and starting with EF4 the easy answer is ignore this - you will almost certainly be using Foreign Key Associations rather than Independent Associations.
A Foreign Key Association is backed by a foreign key relationship in the database and this relationship is explicitly described in the conceptual model. This kind of association is new to EF4 and I understand it is a concession following the issues people had with Independent Associations.
Strictly if you want to separate the storage schema and the conceptual schema (which is kind of the point of EF) you wouldn't want your conceptual schema to know about things like foreign keys as these are a database (i.e. storage) concept. Earlier versions of EF followed this approach and we have this thing called an Independent Association.
Think of Independent Associations as associations that are tracked by EF without the knowledge of the underlying foreign key. EF still supports this but they have significant weaknesses.
EF4 in VS2010 will use your Foreign Keys and create Foreign Key relationships unless you tell it otherwise. On the whole these work as you would expect. There are still some gotchas - e.g. around cascading deletes.
If you want to learn EF - I can recommend this book:
http://learnentityframework.com/learnentityframework/
Everything you want to know, very clearly explained.
Say I'm building a model from a blank canvas in EF and I have a one-to-many relationship in the model (Category->Product or something). How can I make that collection (Category.Products) a Set (HashSet or similar) instead of a collection, so that I can enforce set constraints (such as uniqueness) at the model level?
I recently have moved to using POCO with Linq-To-Sql and really like the freedom it gives to not have to use EntitySet et al. So I think POCO is the answer for you, but I suspect (haven't researched it so can't answer definitively) there are going to be restrictions on what types you can use for your associations and the framework (EF or L2S) still be able to use them. For instance, you probably have to use something that derives from IList, or whatever.
I was looking at something vaguely similar a bit ago, and found that one of the features of EntitySet is the ability to subscribe to the Add and Remove events. There is an ObservableCollection type that also has similar functionality, so you can look into those. Otherwise, you're most probably stuck rolling your own.