I'm trying to start an application and my idea was to rattle off the entities first using the command line and then work on the UI. This is proving trickier than I first thought because under certain circumstances you get a warning saying the generator won't work. It's things like whether it's a OneToMany or a ManyToOne or whether this entity is the owning side of the relationship.
What's the best way around this?
If I can work out the rules then I can maybe decide what order to create things in. My worry is that with a complicated schema there is no order that can work without some warnings and things not working.
My other idea was to generate the entities without relationships first and then edit the json files to add the relationships. Then maybe I can run the generator again on each entity. Not sure if that would work though and I'm not 100% sure of the correct json properties required.
What have other people tried?
Plan your entities and relationships, so that when you create an entity all the entities it depends on have already been created. One way to do this is use a schema designer or just document the entities and put them in the order they need to be created.
Otherwise, as you know, you'll have to manually wire those relationships, or recreate them with the entity generator.
But, even with planning, you're going to have to use a mixture of these methods in the real world. It just depends on how much you've modified the generated code as to which method is the fastest.
Rori's answer is basically what I did but I wanted to provide some extra detail.
First I went through the generator and created every type of relationship to see which ones worked and which ones gave a warning. I was finding that sometimes it worked and sometimes it didn't but it wasn't documented anywhere why.
These relationships always work.
OneToMany
OneToOne (not owner)
ManyToMany (not owner)
These relationships only work when the other entity already exists.
ManyToOne
OneToOne (owner)
ManyToMany (owner)
The reason they don't work is always the same. All of these require a foreign key to be created on the other table which jHipster can't do if it doesn't exist yet. You could of course ignore the warning but I wasn't sure if this meant anything else wouldn't work.
Based on these rules I made a list of my entities and put them into an order that would work without warnings. If an entity had a relationship that may give a warning then I just made sure the other entity was created first.
This seems to have worked. The only thing I've found is that because the generator is a one time thing (you can't use it to modify an entity), you have to know your schema up front and generate the lot in one go.
Related
I have a Core Data model that includes Document Entities and Quote Entities. There is a many-Quotes-to-one-Document Relationship in the model.
I am introducing a new type of Quote, so I would like to create a parent BaseQuote Entity, that will have TextQuote and ImageQuote 'child' Entities. The existing Quote will become a TextQuote.
So, I need to push the Quote side of the Relationship down the hierarchy into BaseQuote.
The lightweight migration documentation says that I can manage "changes to hierarchies" and "changes to relationships", but is not clear that it handles both at once!
If I check the mapping, Core Data thinks it is possible, inferredMappingModel does not throw an error:
NSMappingModel.inferredMappingModel(forSourceModel: lastVersion, destinationModel: thisVersion)
However, when I run the migration I get a crash with the message:
Validation error missing attribute values on mandatory destination relationship
It turns out the relationship is not being correctly populated by the migration - although structurally it seems to have worked.
Has anyone tried this before and got it working?
I think this is beyond lightweight migration. The page you link to explains that relationship changes include adding, deleting, renaming, and changing to-one to to-many or back. What you need is to move the relationship from one entity to a different one in the hierarchy, that is, take a relationship to Quote and move it to the new BaseQuote. It would probably be fine if you were changing the hierarchy and making one of those changes (renaming the relationship, for example). Lightweight migration doesn't cover re-targeting a relationship to a different part of the hierarchy, though.
I have a simple use case where the user can discard a profile. It is really easy to understand but raise some modeling questions.
1/ Is it okay to have a flag in my profile entity to indicate that he is in the trash ?
I don't think. So I would like to have two ProfileRepository and TrashRepository.
2/ So given those two repositories, in my application service I just have to remove the profile from his repository and add it to the trash. Seems natural but can cause troubles if I cannot have a transaction. (but it is not the case in my app).
However, I'm using a relational database and a first idea would be to use a column to indicate if the row is in the trash or not and having the two repositories working on the same table. I'm not sure that it is a good idea.
I can also add a discard method to the ProfileRepository so that I don't need the two.
Which is the best solution ?
Can I set a flag to determinate the status (discarded) in my entity or is it better to have two different entities with different repositories ?
Discard really is a business command and a command will always mutate the state of the domain. I believe that it's perfectly valid to have a status indicating that the profile has been discarded. What would be wrong is to introduce a property such as deleted or active when what you really mean is discarded.
However, some thinks that it's sometime useful to model states explicitely: have an entirely different class to represent a discarded profile.
Here's a few links related to explicit state modeling:
http://codebetter.com/gregyoung/2010/03/09/state-pattern-misuse/
http://p2p.wrox.com/book-patterns-principles-practices-domain-driven-design/94718-ch16-explicit-state-modeling-identity-map.html
https://medium.com/#martinezdelariva/explicit-state-modeling-f6e534c33508
I'm able to work with objects on a context and work with relationships. My registered objects are behaving correctly.
My store is added to the coordinator with the correct configuration (the configuration having 3 entities, one entity with the two other entities having a to-many relationship to the first entity).
Saving the store with either -many entity or with both -many entities works correctly. However, when I add the one- entity to the context, the object graph will not save.
It seems like it would be a common beginner's problem, but that means its also a difficult solution for beginners. I expect I'm not the first one to have run into this kind of trouble?
UPDATE: Thank you for the replies and pointers. It seems the main trouble is as subtly pointed out, that I am not handling errors properly. After looking at this post, Core Data Entity Relationship Does Not Save Between Launches , I have started improving with error handling. The localized description on this issue was 'ID required'. While I still don't know what that means, I can at least have the chance to figure it out, now.
To-Many relationships are represented as sets on the object. So child ->> parent implies that child.parent is represented as a set. Therefore, when you add a new parent object, you need to add that parent object to the set before you save the context. If you say self.parent = inserted_parent_object, I am not sure what would happen. If you are going the other way around it is easier. When you insert the parent object, just set the child (assuming you have it) and save the context. That will work unless it is a many to many relationship.
If there is an error, the code and the error message would be helpful in order to help you debug.
This one has code:
CoreData adding relationships to-many
I´m a little confused about inheritance and relationships in core data, and I was hopping someone could drive to the right path. In my app i have created 3 entities, and none of them have (and are not suppose to have) common properties, but there´s gonna be a save and a load button for all the work that the user does. From my understanding I need to "wrap" all the entities "work" into an object which will be used to save and load, and my question is, do I need to create relationships between the entities? Because I have to relate them somehow and this is what make sense to me. Is my logic correct?
I'm implementing a budget calculator, and for the purpose of everyone understand what my issue is, I´m going to give an practical example and please correct me if my logic is incorrect:
Let´s just say you are a fruit seller, and because of that it´s normal to have a database of clients and also a fruit database with the kinds of fruit you sell. From my understanding I find two entities here:
Client with properties named: name, address, phone, email, etc.
Stock with properties named: name, weight, stock, cost, supplier, etc.
TheBudget with properties named: name, amount, type, cost, delivery, etc.
I didn´t put all the properties because I think you get the point. I mean as you can see, there´s only two properties I could inherit; the rest is different. So, if I was doing a budget for a client, I can have as many clients I want and also the amount of stock, but what about the actual budget?
I´m sorry if my explanation was not very clear, but if it was..what kind of relationships should I be creating? I think Client and TheBudget have a connection. What do you advise me?
That's not entirely correct, but some parts are on the right track. I've broken your question down into three parts: relationships, inheritance and the Managed Object Context to hopefully help you understand each part separately:
Relationships
Relationships are usually used to indicate that one entity can 'belong' to another (i.e. an employee can belong to a company). You can setup multiple one-to-many relationships (i.e. an employee belongs to a company and a boss) and you can setup the inverse relationships (which is better described with the word 'owns' or 'has', such as 'one company has many employees).
There are many even more complicated relationships depending on your needs and a whole set of delete rules that you can tell the system to follow when an entity in a relationship is deleted. When first starting out I found it easiest to stick with one-to-one and one-to-many relationships like I've described above.
Inheritance
Inheritance is best described as a sort of base template that is used for other, more specific entities. You are correct in stating that you could use inheritance as a sort of protocol to define some basic attributes that are common across a number of entities. A good example of this would be having a base class 'Employee' with attributes 'name', 'address' and 'start date'. You could then create other entities that inherit from this Employee entity, such as 'Marketing Rep', 'HR', 'Sales Rep', etc. which all have the common attributes 'name', 'address' and 'start date' without creating those attributes on each individual entity. Then, if you wanted to update your model and add, delete or modify a common attribute, you could do so on the parent entity and all of its children will inherit those changes automatically.
Managed Object Context (i.e. saving)
Now, onto the other part of your question/statement: wrapping all of your entities into an object which will be used to save and load. You do not need to create this object, core data uses the NSManagedObjectContext (MOC for short) specifically for this purpose. The MOC is tasked with keeping track of objects you create, delete and modify. In order to save your changes, you simply call the save: method on your MOC.
If you post your entities and what they do, I might be able to help make suggestions on ways to set it up in core data. You want to do your best to setup as robust a core data model as you can during the initial development process. The OS needs to be able to 'upgrade' the backing store to incorporate any changes you've made between your core data model revisions. If you do a poor job of setting up your core data model initially and release your code that way, it can be very difficult to try and make a complicated model update when the app is in the wild (as you've probably guessed, this is advice born out of painful experience :)
My original data model has an entity "Game". I have now updated the model to include an entity, "Match", which can refer to multiple games. I wish to add a Match to all of my old Games, and ideally this would be a non-optional relationship.
Currently I am setting Match to be optional, and simply adding a Match to every old Game in application:didFinishLaunching after the model has been updated. This works, but I'm wondering if this is really the best way to do it.
I have tried to follow the tutorial here, but I am getting stuck on the part with "StepOneEntityMigrationPolicy.m". I have created an NSEntityMigrationPolicy subclass and set it in the mapping model. I've tried overriding both createDestinationInstancesForSourceInstance and createRelationshipsForDestinationInstance:, but neither get called.
Is this perhaps because my Source and Destination are both the same (GameToGame)? Also, is there any benefit to doing this via the mapping model rather than as I am doing it now?
I think the simplest and most pragmatic way is what you are doing now, i.e. inserting the necessary new entities "manually" after an update. This is a common way to populate orphaned entities after a model version upgrade and perfectly fine.