I am working with the core data model in Xcode 5 and I am trying to code an app for school that helps me determine my grades. I need the app to show a table view of each class and then when you select one, it takes you to the next page and from there you can add sections (ex. test, quiz, hw, etc.) and be able to add the percent and grade for each.
Now my question is, should I be using 2 entities or just 1? I was thinking two (class and section) and then just use multiple sections per class. But would anyone advise doing this? If so, how should I go about making the class entity the "parent" or the section entity? or maybe there is a way to do it with just one entity and work with multiple sections within it.. Any advice or answers would be appreciated.
Create two entities (Class, Section) and make one to many relationship between class and section. As each class may have multiple section, relationship is the good approach to do this.
class<---------->> Section
Refer this link for relationship sample.
http://www.raywenderlich.com/14742/
Related
I am new to swift and I am currently having trouble figuring out how best to go about designing my core data entity map.
My class diagram defines:
1) a student object
2) subject objects
3) event objects (which is a parent class to 3 types of events: Study session, assignment and test, each with various unique attributes)
The idea is that the student is linked to the subjects that they take, and when they create an event (be it a test, or a study session), the event needs to be linked to its relevant subject.
I've read quite a bit about inheritance in core data but a lot of them contradict each other so I am hoping someone can give me an answer based on my specific (although not complex) needs.
Thanks in advance.
If you break it in parts you have:
Student to Subject: What is a many-to-many relationship as a student can subscribe to many subjects and a subject can be subscribe for many students
Subject to Event:
This can be in two ways:
Many-to-many:
where a Subject can have many events related to it and an event can be related to many subjects
Many-to-one:
Where a Subject can have many events to it but each event belong to just one class
In this scenario Students don't get linked to Events directly as it is depending in with subjects the student is taking.
You can set to-many in the xcode as show bellow:
To set many-to-many you have to set this option in both tables.
I am not sure if this was what you are looking for, but I hope it helps you.
I am newbie in core data, and my problem is to store multiple records in core data.
I have two tables first is "Products" which has just product info and second one is "Brand" which has brand info plus this have to have multiple records, so for recording multiples products I am getting confuse on how to have multiples products in Brands.
There are two solution plus with some confusion in my mind which I want to clear from some expert guys or who worked on it.
If I create relationship with 1 to many of brands with products table, then when I'll create NSManagedObject class for Brands, its will has NSSet class with products. My confusion is that will I be able to use this as array or as multiples records of products.
I will add attribute of products with Binary Data and then convert this into NSData then into NSArray. My confusion is at this solution is that, Do I need to have relation Brands with products still after adding attribute of products or this will be fine If I'll don't have and if this fine then what is use of relation.
Kindly explain me any one expert, I am confuse over here, and looking for healthy response.
Thanks in advance.
Best would be if you go with relationshipas that way u would be able to get back n forth for information. Also NSSet class would help you to code down your info into core data easy way. Also relationship would help to filter out stuff if you would require search feature or any other future implementation. Anything else let me know.
I recently asked this question about how best to retrieve and display in a tableview the titles my FRC is using for section headers.
Following a line of research suggested by #Mike Pollard in the second answer to my question, I ran across this question and was immediately struck by the similarity to my situation, and by the 4th answer, posted by #aroth.
Aroth's approach certainly appears sound, and I've created a new Category entity. Specifically, Category has a to-many relationship with Item, and Item has a to-one relationship with Category. However I'm having trouble understanding one aspect implicit in his proposed solution, and, more fundamentally, in this relationship:
In my case, both Category(s) and Item(s)--"Item" is called "ListActivity" in my case, but "Item" will do for illustration purposes-- will be named via two corresponding user input fields, which seems like it could result in multiple entries of the same name in the Category list.
My question:
How can I ensure that when I fetch a list of Categories that I get a singular instance of each category, i.e., one category per row in the tableview, with no repeats? Will Core Data automatically assign each new incoming Item to a singular instance of the appropriate Category via the relationship? Or will it somehow test for and winnow the list down to one entry per Category name upon receiving the fetch request? Or must the filtering be done with a predicate in the fetch request?
Thanks!
Core Data will do what you tell it to. This sounds like an issue related to you creating content in your data store rather than an issue with the FRC and table view. It's your responsibility to search for and reuse existing objects rather than creating duplicates and adding them to the store - indeed, only you (your code) knows what constitutes a duplicate.
So, basically, as you create new items, use a fetch request and predicate to find the suitable existing category (or suggest categories based on partially entered names). Then, either connect to the existing category or create a new one.
I'm struggling with creating a suitable Core Data model for my app. I'm hoping someone here can provide some guidance.
I have two entities -- "Goals" and "Items". The Goals entity contains only a goal description, but any goal may have any number of subgoals, and these may extend multiple levels in a tree structure. Subgoals are to be contained within the same entity, so presumably the Goal entity will contain a pointer to "parent" which will be the parent goal of any subgoal.
There will also be an "Items" entity that contains a couple of text fields and a couple of binary items, and must be linked (ideally, by a unique identifier, perhaps objectID) to the particular goal or subgoal the item(s) are related to.
I am totally fumbling with how to set this model up. I know what attributes need to be in each entity, but the relationships, particularly between goals and "subgoals", has me stumped. I don't seem to be able to turn up any good examples of tree structures in Core Data on the Internet, and even the couple of books I have on Core Data don't seem to address it.
Can anyone here help an old SQL programmer get headed the right direction with these relationships in Core Data? Thanks.
Have you tried creating a one-to-many from Goal to itself, and a one-to-one from Goal to Item? The only thing I would worry about here is circular references.
Also, read Relationships and Fetched Properties in the CoreData Programming Guide.
Here is how it is done:
You set up a to-many relationship from Goal to Item in the model editor. Don't use any ids, foreign keys etc. This is old-fashioned database thinking - you can forget about it. Here we are only dealing with an object graph. The database layer is just an implementation detail for persisting the data.
Make two more relationships in entity Goal to itself: a to-one called parent, a to-many called subGoals. Make them the inverse of each other. Simple!
QED is correct, you can create a to many relationship on goal (call it subgoals) as well as a to-one relationship on goal (call it parentGoal) and set them as inverses to each other.
Then create another to many relationship (call it items) on the goal entity, with the inverse being a to one relationship on the item entity (call it goal). Then you're all set. You don't need to link items with a unique id, just add them to the items relationship.
Also note that if you did want to give items a unique id, do not use the objectID. The objectID should only be used as a temporary id as they are not guaranteed to remain the same. In fact they will change if you ever do a Core Data migration.
One way, though not really great, is to create a another entity, say subGoal, and each goal has one subGoal and each object of subGoal has many goal.
I'm in a hypothetical situation in which I need to list students in a school. I have one table view controller that has several sections, representing a school. Each school has subsequent students. Now, I have the requirement to give the user the capability to view all students for a particular school by clicking on the school name in a top level view of my navigation controller.
The question here is, do I branch out my current "StudentsViewController" and add complex logic in order to allow it to display an individual School's students, or would you experts recommend a new class to handle that table?
The tradeoffs are rather straight forward in that I can indeed probably put everything in one view controller at the cost of some confusing/complex logic. On the other hand, there will be a great deal of repeated code if I write another controller that handles an individual school's students.
What do the experts recommend on this one?
I think the simplest thing to do would be to have a single class that handles an array of schools. If that array contains only one item, you can (optionally) have no title displayed for the single section. Otherwise, all sections have titles.
Put all your schools into an array, and when a single school needs to be displayed, stick it into an array by itself, and push that into your view controller.
We do a very similar thing in one of our apps, in basically the same way.
I think it would depend on the model you are using to hold your data.
Lets say you have an array of arrays,
(array of schools, each school holds an array of students.)
In this case, I would stick with one tableController.
The logic doesn't have to be hairy if your model design is simple, and I think it would be cleaner and "more correct" than multiple subclasses in this case.
Don't forget anywhere the system passes you an NSIndexPath you have the section and row numbers. (School and Student)
indexPath.section and indexPath.row