I'm currently migrating my sqllite application to using core data. When I created the data model I noticed that an attribute can be marked as and Identity property. Happily I marked that attribute as required and indexable only to find out that I have to supply the value myself or the insert of the entity fails, which kind of takes away from the idea of the data store providing the identity for me.
So if the identity property doesn't work like I thought it does, does anyone as any idea what its for?
Digging in the documentation and on this site it became clear that core-data as it's own identity object. Is this what I'm suppose to use? Is this how relations are created between entities?
The attribute which marks a property as an identity property in the modeling tool is in the Sync Services pane and is only used by Sync Services, not Core Data itself.
You aren't supposed to worry about CoreData's internal identity but rather manage your relationships by creating the proper relationship associations in the CoreData designer and associating actual objects rather than ids.
Related
I am currently working on a project which may require the ability to generate a Core Data model and classes automatically from a JSON feed which describes each object, it's properties and relationships. This would enable our company to quickly generate a working core data database from our CRM at the start of each project.
Is this possible/easy to achieve? If so, does anyone have any tips on where I can get started?
I have already created various iOS apps which use Core Data but I have never made one which needs to automatically create a Core Data model.
Yes, you can create a Core Data model dynamically. An NSManagedObjectModel can be created without a stored model, and NSEntityDescription/NSAttributeDescription instances can be defined and added to it before being passed to an NSPersistentStoreCoordinator. Apple has an example of doing this in their Core Data Utility Tutorial.
I get an NSInferredMappingModelError when I try to migrate my model.
During the migration, the objects of an entity Example are migrated from having a to-many relationship to a to-one.
The migration fails with the error when it tries to make an NSMappingModel via inferredMappingModelForSourceModel.
I need to use custom migration because of the nature of the project - the program operates on (ideally) any kind of model.
Any ideas or nudges in the right direction?
Because lightweight migration cannot deal with the change you've made, inferredMappingModelForSourceModel is going to fail. You have to create the mapping yourself and load it with mappingModelFromBundles.
It is hard to go into a lot of details here without knowing more specifics but you can learn more about custom migration in Apple's Core Data Model Versioning and Data Migration Programming Guide. You might want to start by looking at the sections "Customizing the Migration Process" and "Mapping Overview".
I have the older version of the core data model of the released app. Now, in the next version of the app, I am migrating the core data model to new model. Is there a way to get the attribute values from the old model before actually migrating to the new version of the model or is there possibly a way to know if the migration is to be occurred.
When you migrate, Core Data actually moves existing values for you. If you're doing a relatively simple migration, such as adding or removing some properties, Core Data does its best to make the move as seamless as possible. In many cases, you won't need to make any changes other than set your new model. See my answer here for more.
Yes, it is possible.
To get the attribute values from the old model you'll need to create custom entity migration policies (NSEntityMigrationPolicy subclasses). Then in -createDestinationInstancesForSourceInstance:entityMapping:manager:error: you'll receive source instance, and it is completely up to you how to create destination instances from source instances.
There is a method to check if a given store is compatible with store coordinator model: -[NSManagedObjectModel isConfiguration:compatibleWithStoreMetadata:].
I have to write a solution that uses different databases with different structure from the same code. So, when a user logs to the application I determine to which database he/she is connected to at runtime. The user can create tables and columns at any time and they have to see the change on the fly. The reason that I use one and the same code the information is manipulates the same way for the different databases. How can I accomplish this at runtime? Actually is the Entity Framework a good solution for my problem?
Thanks in advance.
You can do this with EF 4 using a code-first model. That said, I tend to avoid changing DB metadata on the fly, with or without EF. Rather, I'd choose a schema which fits the user's changing needs.
I'm working on proof of concept application like crm and i need your some advice.
My application's data layer completely dynamic and run onto EF 3.5. When the user update the entity, change relation or add new column to the database, first i'm planning make for these with custom classes. After I rebuild my database model layer with new changes during the application runtime. And my model layer tie with tightly coupled to my project for easy reflecting model layer changes (It connected to my project via interfaces and loading onto to application domain in the runtime).
I need to create dynamic entities, create entity relations and modify them during the runtime after that i need to create change database script for updating database schema. I know ADO.NET team says "we will be able to provide this property in EF 4.0", but i don't need to wait for them.
How can i update database changes during the runtime via EF 3.5 ?
For example, i need to create new entity or need to change some entity schema, add new properties or change property types after than how can apply these changes on the physical database schema ?
Any ideas ?
This blog post may have what you need. It describes a way to capture the metadata of your model and modify it in-transit, during runtime. I haven't a clue how it works, but it sounds cool.
Changing Entity Framework storage DB schema during Runtime
http://blogs.microsoft.co.il/blogs/idof/archive/2008/08/22/change-entity-framework-storage-db-schema-in-runtime.aspx