I have a model that has an abstract entity with two entities that inherit from this abstract entity.
When I try doing automatic migration I get an error about there being no mapping model so I created a mapping model and then get errors about multiple validation errors.
Looking closely at the mapping model that has been generated neither of the entities have any attributes from their parent included in the mapping model, one of which is not optional and seems to be generating the error during migration.
Is it possible to use automatic migration when abstract entities have been used ?
If not then I am busy creating a custom migration class using the following simple statements to migrate each attribute.
[newObject setValue:[sInstance valueForKey:#"name"] forKey:#"name"];
How do I migrate relationships ? Can I use the same approach for relationships shown below ?
[newObject setValue:[sInstance valueForKey:#"parent"] forKey:#"parent"];
[newObject setValue:[sInstance valueForKey:#"children"] forKey:#"children"];
Thanks.
OK I found my problem - DO NOT make any small changes to your original data model because things will fail !!!
I have mistakenly made a change to the original data model, once I have figured out what this was and reset it things started working.
To overcome the abstract entity problem I had to create a CustomMigrationClass which copies each attribute and relationship across. All works nicely now.
Related
I am working on an iPad application, that requires me to store data locally if the user doesn't have internet access and later on sync with the back-end database.
For local storage, I am planning to use Core Data with SQLite.
I am using Core Data for the first time and it seems, it retrieves entity and store entity in the form of a dictionary.
So should I be creating Model classes at all ?
What is a good design for such application.
I have a DataEngine class whose responsibility is to store entity on a server or local DB based on connectivity.
Now I am little confused If I need to create a Model class and ask individual model classes to save themselves using NSMangaedObjectContext with a dictionary representation Or just directly save data instead of creating a model object and asking it to do it ?
Should I be using a Moel class for each entity and that will server as interface between JSON representation that coms/goes from/to server.
and the representation I get from managedObjectContext.
Or shall I compeletely rely on the entity and relation ships that Core Data creates ?
I'll do this backwards: first some things for you to check and then some ideas.
Check my own question.
I'd say that on your custom categories you can do the interface between the JSON representation and your classes.
You should also check RestKit which can do already much of what you need.
You're talking about two separate problems as far as I can understand:
Syncing local data to the server based on connectivity;
Using model classes.
Problem 1
I think you should have a class with the common code and each of your model classes should have its own mapping (to map between model and JSON) and saving methods.
Another class, that may be your DataEngine class, takes care of saving the right objects at the right time.
Take a look at RestKit as it helps with the mapping and the saving. I'm not sure about the syncing though.
Problem 2
I think you should have model classes. It helps a lot to work with objects and you have then a place to save methods for finding different kinds of data.
For this my question might be useful for you because you can create a CoreData model with generated class files and update it whenever you want while keeping your custom code.
I'm using Symfony2 and Doctrine 2.0. I'm trying to read data from an XML feed and map this to new or existing entities in the database. When data in the XML feed changes I need update existing entities, but when the data is added I should create new entities.
In my entity classes I'm using the following denormalize methods to map the XML data to the entity's properties:
function denormalize(SerializerInterface $serializer, $data, $format = null)
(Defined in Symfony\Component\Serializer\Serializer called inside my Entity classes)
The docs for this method state that "It is important to understand that the denormalize() call should denormalize recursively all child objects of the implementor." and this is what I'm trying to do. However entities should not know about the EntityManager so how do I check, inside the denormalize() method if a related/child entity already exists or not?
Kind regards,
Matthew
It is indeed a bad idea to call the EntityManager in an entity (and, as far as I know, outside a controller).
I've never faced that problem, but if I were you I'd try to denormalize in one of your controllers, or if it really bothers you, in a service that you call in a controller, and to which you give your EntityManager (here again, best do it in the controller itself, or simply send your objects to the service so it can denormalize the xml "into" the objects).
Best would be to write a controller that works no matter the entity given.
Hope that helps!
I think my problem was in my approach and not really my code!!
Originally, each time I found an entity represented in the XML I would check (using the EntityManager) to see if it was new or existing BEFORE denormalizing it. I took this route because there is duplication in the XML and I was worried about creating duplicate entities in the EntityManager. Cheacking to see if an entity already existed meant I could update the existing entity rather than create a duplicate. Now with my new approach every time I find an entity represented in the XML I denormailze it into a new entity. Of course this creates duplication in the EntityManager, just as there is in the XML, but this can be handled later, hopefully..!
So far this is proving to be a better solution, although I am experiencing some issues when trying to merge the duplicate entities in the EntityManager using $em->merge(); and cascade={"persist", "merge"}. I've posted a new question about this here: Doctrine 2.1 - Relation Lost After ManyToMany Cascade Merge - Symfony2
Matthew
I've come across a bit of a problem when I try and migrate my data model from old to new. I've been searching the web and trying to find a solution to this issue for a couple of weeks now, but still no luck.
This is what my data model looked like like before:
A <<--->> B
<<--->> C
And after:
A <<---> B
<<---> C
As you can see, the relationships between the entities A to B and A to C changed from a many-to-many relationship to a many-to-one. The problem is getting the migration to work. If I try it using light weight migration, I get this in the console (along with a lot of other stuff):
Can not map from a to-many to a to-one relationship.
This makes sense when considering the documentation. So I guessed that I needed to use a mapping model and a custom migration policy to handle the relationship change. If I use the mapping model that is automatically generated, I just get an "Unresolved error" and about half way through the log, it says that it can't find the mapping model for migration. I'm assuming that this is like a generic error description as a trivial change to the model (i.e. changing the name of something) works (meaning that it can indeed find the mapping model). So my question is: how do I get the mapping model to migrate the store correctly? And can you please be descriptive as to what I need to do to accomplish this? I'm guessing I'll need to use this method:
- (BOOL)createRelationshipsForDestinationInstance:(NSManagedObject *)dInstance entityMapping:(NSEntityMapping *)mapping manager:(NSMigrationManager *)manager error:(NSError *__autoreleasing *)error
in the custom policy, but what code do I need in this method to make it work (if you can even just generalise on it)?
By the way, I'm using Xcode 4.3.2 and the minimum iOS requirement for this application is iOS 5.
Thanks in advance for your help.
And here goes yet another question on NHibernate.
This one most likely doesn't have a desired answer, but still - let's give it a try.
I'm currently putting all the efforts into mapping a domain model onto the database using NHibernate. This domain model comes from a framework which is heavily obfuscated. (Not that I have worked a lot with obfuscated code before, but this one in most of the places can be translated neither by Reflector, nor by Resharper.)
Everything went more or less fine until I faced an entity with a required many-to-one relationship represented by a property with no setter with obfuscated backed field.
Is it possible to reference this obfuscated field somehow? A very special IPropertyAccessor?
If not, how can I load a fully constructed entity? The only option to inject a related object is by using a constructor that accepts it. But at the time of instantiating of an entity being loaded, neither IInstantiator nor IInterceptor has any data of it apart from the key. Any other extension points that suit my need?
To allow NHibernate to access your field instead of property you can use this in your mappings:
access="field"
I have a situation where I have a Common.Domain.Person and Specific.Domain.Person.
First one should be provided as a part of a common package.
Second one appears when common package has to be customized to fit the needs of specific project.
In the object model, it can be easily implemented with inheritance.
In the NH mapping, however, I have encountered a small problem.
I can create an NHibernate <subclass> mapping, but that would require me to use an discriminator. However, I know that if specific person class was inherited, then common class instances will never be used within this specific project.
What is the best way to implement this without adding discriminator column to the base class (since there are no different cases to discriminate)?
this is what i wanted and nhibernate supports it using xml entities. Unfortunately this feature has been borked since (at least) NH v2++.
see also Using Doctype in Nhibernate
A work-around could be to inject these properies programmaticaly when you create the SessionFactory (Dynamic Mapping)
see also http://ayende.com/Blog/archive/2008/05/01/Dynamic-Mapping-with-NHibernate.aspx
Just map the Specific.Domain.Person and leave Common.Domain.Person unmapped.
If you are not saving instances of it, NHibernate does not need to know about it.