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.
Related
I'm struggling to get my model's entities to be change tracker proxies rather than utilize snap shot change detection.
My entities are created by the EF designer and have been otherwise unmodified. I followed the steps in Programming Entity Framework: DbContext but my entities never seem to inherit the IEntitiyWithChangeTracker (though they are in fact DynamicProxies).
Can anyone enumerate the steps to make an entity created by the DataBase First EF 6.1 designer into a change tracker proxy? I assume that modification of the classes must be made outside the designer, nothing will be automatic.
So, the answer lies in using the correct Namespace for IEntityWithChangeTracker. In EF6.x if you test with System.Data.Entity.Core.Objects.DataClasses.IEntityWithChangeTracker your entity will return true. Thanks Fred Bao of MSFT
I am using CoreData in my iOS application. I face a problem most of the times while creating NSManagedObject classes.
This is what I do:
I create an Entity in .xcdatamodeld file.
Create attributes and relationships.
Choose option Editor->Create NSManagedObject Class to create .h and .m classes.
In .h and .m classes, I create some of my custom methods for fetching/saving objects.
So far so good. But afterwards in future if I have to change some attributes, I repeat step 2 and 3. But this time all of my custom code written in step 4 are removed automatically.
So my question is how can I update the existing classes? Instead of using option Editor->Create NSManagedObject Class which removes all my custom code.
Any help is appreciated.
Update:
Tested both approaches (Categories and Mogernator) and looks fine to me. But I have choosen Categories of being a pure Xcode approach. I don't want to take the risk of any 3rd party which may break in future due to XCode updates or can cause problem of data migration.
Thanks to #Tom Harrington, and #Valentin Shamardin for guiding me :)
To make some additional methods or other stuff for your Core Data model classes you have to create Categories. This approach is used by Paul Hegarty in Core Data lections.
The best way to handle this is to use mogenerator to generate your model classes instead of having Xcode do it. With mogenerator you get two classes for each entity:
One that is re-generated every time you rebuild the model classes
One that is a subclass of the other, which is only generated the first time you build model classes and which mogenerator never changes afterward.
As a result you can put all your custom code in the subclass, and no matter how many times you re-generate your model classes, your code is never overwritten.
Whenever yo change or update your core data object model it becomes incompatible and cannot be open and as a result it gives crashes.
For this you need to perform Core Data Model Versioning and Data Migration.
Versioning is nothing just only provides you which model version is application going to use. Changes and update in core data model like modifying any attribute of entity or adding new entity. It is related with Core database model. Consider your application going to use 1.0 ver and using database model of 1. if u have some changes in database model its version increases and now you application going to use next version ie 2 of core database model
The details refer to this Apple Doc for Core Data Versioning
Also this will result in old Data loss. For this you need to perform Migration Process.
During migration, Core Data creates two stacks, one for the source store and one for the destination store. Core Data then fetches objects from the source stack and inserts the appropriate corresponding objects into the destination stack".
Please refer to Migration Process details on Migration on Raywenderlich
You need to use NSMigrationManager class and
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
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 have an Entity Framework 4 project with many POCO Entities (50+) that are automatically generated from the edmx file using a template. They all default to use Proxies and Change Tracking. Everything has been working great, until I noticed that one of my Entities all of a sudden is not using Change Tracking. When I look at the Entity Wrapper of the ObjectStateEntry in debug mode for this entity only, it shows that it is an EntityWrapperWithoutRelationship, and that the ChangeTrackingState is set to Snapshot. I have not done anything different to this specific entity, although it is a large entity with many navigation items attached to it. They are all automatically set as ICollection properties, and they all are virtual properties. This entity does not have any complex properties. It does have a computed field, but I don't think that has anything to do with it. Like I said, this entity was working fine like the other entities, but I cannot figure out why it no longer is. And I have made too many changes to the entire application and edmx file to know what it could be. I could really use some insight into what could be causing this.