Hi I'm trying to create a follower-following model (like Twitter) in Core Data. Maybe I'm too used to using IDs, I'm not sure if this correct. If possible, can someone please give me some advice.
Thanks
If I understand your problem correctly, you need only the "BDOUser" entity and a "many-to-many" relationship from "BDOUser" to itself.
Define "followers" as to-many relationship from "BDOUser" to "BDOUser".
Define "followings" as to-many relationship from "BDOUser" to "BDOUser".
Set "followings" as inverse relationship to "followers".
Now you can do things like
[userA addFollowersObject:userB];
That will
add "userB" to the followers of "userA", and automatically also
add "userA" to the followings of "userB".
Related
I've looked all over SO, youtube, and the Apple docs and am having real trouble understanding the distinction--if any--between parent/child and to-one/to-many inverse relationships in Core Data. Nothing I've found appears to address the subject directly and explicitly.
I need to know this because I want to load a table view with data from one entity, called ListActivity, grouped into sections defined by another entity called ListCategory, as shown here. Also not real confident of my naming convention:
Can someone please clearly explain the difference--and when to use each case--or point me to something that can?
Thanks!
Edit for clarification:
For comparison, here is a screenshot of my entities with ListCategory specified via the menu in the Data Model Inspector as the Parent Entity for ListActivity:
Relationship is used go down in an object graph (i.e activities in a category) while an inverse relationship is used to go up in an object graph (i.e category to which an activity belong to).
While naming convention looks fine. better use "activities" instead of "listActivities" and "category" instead of "toCategory".
Generate classes for them and you'll better know how these will work out.
I am using coredata to save the server data through web services in my application and I am storing relationships as an object to the entity.
I have many entities e.g "Inspirations" and "Products" and both are related to each other. I have a problem whenever the records are updated in the third entity which is "Filters" then the relations of the entities broke and I cannot apply filters on the entities.
[object addRelatedInspirationsObject:related];
This is how I save relationships. I am not able to figure out why the relations are being broken once the entity is updated which has no direct link with the entity.
One thing more if I fetch and save the data of any one of the entities like "Inspirations" then all the relations start to work again.
Your code should work. Here are 2 things you need to check:
Make sure related is not nil when you call your method.
Make sure you call save on a valid managed object context.
From your question it seems that entities have 1 to many relationship between them. And by the code you supplied, every things should work fine. Just make sure, you are using the Filter object from the relationship like object.filter (or obj1.obj2.filter), not accessing it via a direct NSPredicate on Filter entity and updating it. And if you are using FRC, you might also need to generate a fault against the parent entities, to get your UI updates.
I want to create friends list in my core Data. I have entity User with relationship friends. My user have attributes (to simplify):
userId
name
I want that he can make friends so i add this relationship:
All friends of course will be have the same pair of attribute.
So when i look into graph i see something like this:
This is correct ? Can i managed it like separate entity? Will creating a new friend create a new user? What is keyword for apple documentation to find an example or description of this behavior?
The relationship is absolutely correct, except that friendship is naturally bidirectional, so inverse relation is friends too. There is no such issue as creating a friend, so it not creates a new user. You can just build a friendship relation between two existing users.
The keyword you are looking for is : Core Data Programming Guide :)
I am fairly new to using Rhomobile, however I am not fully understanding how the local storing works and how to use the Rhom API.
I've set up the RhoStudio and run the configurations.
What I am trying to achieve is basically have two data models (with property bags as default): one for wards, and one for patients so I can create patient and ward objects.
Eventually I would like to list the wards, and the patients that are assigned to the ward objects.
Can someone explain how I use the Rhom API to be able to achieve this?
I have ran a simulation so once I have something like: /app/Patient/{131199009368684.14}/show in the web inspector, so I am assuming that I will need to create an association of some sort.. And then filter it out with a group Query.
In my personal opinion using the RhoMobile Doc's are not helpful enough.
Many thanks if someone can give me a typical example.
Rhodes auto generates unique ids for each instance of a Module, when it is created. This property is called "object". "131199009368684.14" what you got is the "object" of a particular patient that you created. What you can do to link the patients to the ward is:-
Add an additional property to the Patient Model that stores the "object" of the Ward instance you want to link that particular patient to. Thus you will be able to list all the patients in a particular ward by running a find query on column that stores the object of the Ward in the Patient table, by supplying it the particular Ward's object.
Hope this is useful.
I'm about to implement a like functionality between a User entity and some other entity, such that User A can like an entity X. However, I'm not sure how to best implement this in Core Data.
There are two main points I need to consider:
Adding another likeable entity should be trivial
There needs to be a way to sync a Like that has been performed offline
My initial thought was to create an abstract Core Data entity Like.
A User has a to-many relationship with Like, and a Like has one User.
Then for each entity that should be likeable, I create a subclass of Like that has a to-one relationship to the likeable entity. The relationship to the User is inherited.
This way, the abstract entity Like can have attributes such as "syncedAt" and "deletedAt" so that it's possible to find out if a Like type entity has been synced to the server or not.
Does this sound reasonable or are there better ways to solve this problem in Core Data? Are there disadvantages to this design that I'm not foreseeing?
why not have a parent entity LikableEntity which your likable entityies inherit from: this could have the synchedAt attributes. The your User has a to-many relationship likedEntities which contains anything it has liked