In my data model I have a Customer object and each customer can have many Address objects mapped as a one to many relationship.
I am using NSFetchedResultsController to get the data for each Customer. However I want to sort the response by city on the Address object.
Please can you show me how this can be done (if possible ta ll). I've tried a few ways but with no real luck.
Thanks
Related
I have been using Core Data to model my database. I have 2 entities that are in many to many relationship. Each person can have many addresses, and on each address multiple persons can live.
Now i would like to add property to this relationship. For example one person - address will have label home, other person - address can will have label mama's place.
I can't add this property on address entity, because same address will have different labels for different persons.
Since relationships are modeled like NSSets, I don't see a way to do what I want.
Can this be somehow done?
It is not possible to add attributes to a many-many relationship directly. The Apple-recommended approach (see "Modelling a relationship based on its semantics" in the CoreData Programming Guide) is to replace the many-many relationship with an intermediate entity, to which you add the attributes. Each of your existing entities will have a one-many relationship with the new entity.
In your case, you might have something like this:
Person <--->> PersonAddressDetails <<---> Address
You can then add the label attribute to the PersonAddressDetails entity.
I have two tables in coredata Details and person.
Person has two fields Id and Code:
Id Code
IAS RT
IAS TP
IAS IP
Now,detailshas two fields,code and Name
Code Name
RT Rataz
TP Tranzps
IP Irrz
Now I want to use predicates so that i can first fetch the id from person,then after getting the field against the id.I can use the same id as predicate to get Name from person table.How this can be achieved.Any help or suggestion would be appreciated.Thanks in advance.
OK, how you should do this is using a relationship.
Add a relationship to Person called "details" and add a relationship to Detail called "people" (or "person" if it's singular).
Now you can get the person by the id and then use person.details to get the details associated with that person.
Core Data is not a database. Think of it more as a data model. Create the data model and object relationships that you need and use them.
You would be better off checking out a core data tutorial. It will help you in understanding how to use core data.
I am working on a project which provides a way to collect data about rooms at a specific address. I have set up a relationship in the data model between the rooms and address tables. The project currently presents a UITableView of addresses which the user is able to drill down via address to another UItableView to view rooms.
This is where I am clueless. If there are no rooms, a custom UIView is presented to enter the room data. The user enters the data in the UIView for each data point and then presses save. The IBAction for the save button currently sets the value for each key in the related table. I am assuming it is here that I need to establish the relationship between an address and its rooms, but I cannot find the proper way to do this. I have tried NSSet setWithObject in the setValue method:
[newRoom setValue:[NSSet setWithObject:_address] roomName.text forKey:#"roomName"];
but Xcode wants me to insert a colon between roomName and text.
Ultimately I want the user to be able to choose an address and manage room data for that address, but I am unsure how to establish the relationship between the address and its rooms.
any help would be greatly appreciated.
It sounds like the Address to Room relationship is one to many: each Address can have many Rooms, whereas each Room relates to only one Address. So the Address entity should have a rooms property to represent the relationship, and the Room entity should likewise have an address property. (If you have used different names for these properties, amend below where necessary).
When the user selects a row in the table view of addresses, you determine the corresponding Address object. Let's call that chosenAddress. Your second table view should then display only those Room objects that relate to the chosenAddress. When you create a new Room object, let's call it newRoom, you can establish the relationship to chosenAddress with:
[newRoom setValue:chosenAddress forKey:#"address"];
or, if you have created NSManagedObject subclasses for Address and Room:
newRoom.address = chosenAddress;
Note that CoreData will automatically set the inverse relationship, adding newRoom to the set given by chosenAddress.rooms.
I'm working on a data-collecting app and I'm having trouble gaining an understanding of how these concepts connect? Here is my scheme:
Site <----->> Station <------->> Observation Event
Site has one attribute, the name of a Site, and can containing multiple stations. Each station will have multiple observations over time. I have these set with the Event to the left as a parent event and created one-to-many relationships as diagrammed, Since each observation event will need to be tagged with site and station.
I'm assuming the parent entity is the best way to create this, or is that what a relationship would do? I expect the user would setup site/station data ahead of time and then observation data would be filled in as they were made.
In short, I just can't wrap my head around what a relationship does in core data and if a parent entity would be redundant. The core data documentation is just not clear to me on this. Any help would be vastly appreciated!!
In essence, what you're going to see when you generate your entity classes, is that in addition to the attributes of each entity you'll have an NSSet for the "to-many" relationship. You can reference any of the "records" in the to-Many relationship by the values in the set.
It seems complicated at first but then it makes total sense. So, if you want to look at the stations, you'll maybe have a "stations" set that includes a list of managed objects for each of the station entities for that site. Each station will contain a set with the managed objects for each of the related observations.
So, once you have a Site entity, you could look at all the stations for that site with something like this:
Site *site = (Site *) managedObjectForSite;
for (NSManagedObject *station in site.stations)
{
Station *stat = (Station *) station;
(do what you need to with the station record)
}
You "link" sites with stations by adding members to the stations set of a given site record, where each member is a station's managed object. You are relieved of the responsibility of "reading" station records -- once you have the members of the set which are loaded with the site, each of those is effectively a managed object for the related stations.
When the light comes on it will all be crystal clear at once. You have to work through it once then you'll pretty much know what's happening in there..
Please also see this as it may help: One-to-Many Relationship: CoreData
In Core Data, relationships have a similar function a foreign keys in a classic relational database setup.
In a database, you would "connect" the Site, Station and Event entities with a foreign key:
Site .id = Station .siteID
Station .id = Event .stationID
In core data this is not necessary. Neither of the two entities needs an extra ID attribute, instead you just define one-to-many relationships.
Site <--->> Station <---->> Event
The advantage: you can access the site from the station, or all the stations from the site with transparent and highly legible dot-notation as you would expect from an object graph. You can even conveniently get the site from an event object, etc.
Site *aStationsSite = station.site;
NSSet *aSitesStations = site.stations;
NSSet *aStationsEvents = station.events;
NSSet *sisterStations = station.site.stations;
Site *siteFromEvent = event.station.site;
I am creating an app that navigates through multiple levels of one-to-many relationships. So for example, pretend that the CoreDataBooks code sample starts with a list of genres, you click on a genre and then get the list of books organized by author as seen in Apple's code sample.
Here is my problem: the Apple documentation tells me I should use a FetchedResultsController to help organize my list of books into sections (among other reasons). But when trying to figure out how to get from "one" genre to my "many" books, the Core Data FAQ tells not to use a fetch. From the FAQ:
I have a to-many relationship from Entity A to Entity B. How do I fetch the instances of Entity B related to a given instance of Entity A?
You don’t. More specifically, there is no need to explicitly fetch the destination instances, you simply invoke the appropriate key-value coding or accessor method on the instance of Entity A.
The problem, of course, is I now have my books in a set, but I want them to get them from a fetched results controller.
What is the best way to proceed here? Should I follow the FAQ, and if so, how do I manage dividing my books up into sections by author?
Or do I use a fetched results controller (which I suspect is better), in which case how do I traverse the one-to-many relationship (since Apple's oh-so-helpful answer is simply "don't")?
Many thanks for your help.
Sasha
You have a data model that looks roughly like this:
Genre{
name:
books<-->>Book.genre
}
Book{
name:
genre<<-->Genre.books
}
In your master table, you run a fetched results controller to get table of Genre objects. Then the user selects one of the row which behind the scenes selects a particular Genre object.
Since every Genre object has a books relationship that points to the related Book objects, you have automatically got a reference to all the related book objects so you don't have to fetch anything. For your book tableview you just create a sorted array of the Book objects in the selected Genre object's books relationship.
Think of a Core Data object graph as a clump of bead strings all woven together in a web or fabric. The beads are objects and the strings are relationships. A fetch plucks one of the bead/objects from the clump but once you have that bead/object in hand, then you can just pull on its string/relationship to pull out all the beads/objects related to the bead in your hand.
So, fetches are used in most cases just to find the starting objects, then you walk relationships to find most of the other objects.
That is why the Apple docs say you don't need a second fetch.