I have a pretty basic question.
If I have two entities with a relation between them (lets say entityOne has a to-many relationship to entityTwo).
When I fetch entityOne, does it automatically fetch its relationships? Or do I have to fetch them as well and assign them to its corresponding entity?
I thought this would be actually better to ask in the chat since its a simple question, but I dont have the reputation needed yet.
Since I can't post my question because its too short, I'll just ask another question.
In the same project, I have a rootViewController which fetches the entities. Now if I want to add an event I have to send the user to another view, with textFields and such. I ended up creating an array "eventArray" for each of those viewControllers since I couldn't find a more efficient way of doing this.
Lets say I have in rootViewController a NSMutableArray *eventsArray and in addEventViewController I have also an NSMutableArray *eventsArray which gets set before pushing addEventViewController (addEventViewController.eventsArray = self.eventsArray).
How do I do this more efficiently? I'm pretty sure this isn't the right way of doing it.
In answer to your first question:
This situation is handled by Core Data automatically, and the mechanism is called "faulting". Apple has some helpful documentation on this. Simply put, the related objects aren't fetched, but when you try to access them, Core Data will automatically retrieve them from the persistent store.
Of course, there may be situations where this one-by-one fetching of related objects (perhaps to display something about the related objects in a table for example) slows down your application.
In this situation you can use the setRelationshipKeyPathsForPrefetching: method on NSFetchRequest to retrieve these objects upfront. It's all a question of balancing memory usage and performance.
Faulting is a very important part of Core Data, and I'd strongly suggest reading the documentation carefully to make sure you have a good understanding of how and when it is used.
Related
i'm refactoring my app. Currently, I store objects in a .plist for further processing. It works fine, but I thought it was about time to dive into CoreData.
My app fetches data from a web service. This data I parse into individual objects.
I use the properties of these objects to fill Tableviews.
While refactoring, I could just bluntly store the whole object as a transformable with CoreData, as far as I understand.
I could also define an entity with attributes similar to the properties of my object.
Is there any Best Practice here? I think the first approach makes it easier to do the refactoring, but I somehow think I'm missing out on advantages of CoraData in that case. Like maybe performance?
Do not store objects as transformable. You will get just DB where it is not possible to fetch some separated objects based on some criteria. You will need to fetch all DB in memory and than work with it. So it will be the same as plist file and you will waste the effort. Just use entities with proper attributes. CoreData is fast, you don't need to worry about performance.
Transformables are generally a good idea only for attributes that Core Data doesn't know how to represent. They let you use a binary data blob as a fallback, but they're never ideal. They can also be used if you absolutely, definitely, will never ever need to filter or sort a fetch request based on the attribute value. In that case they're still not great, because there's extra unnecessary work.
If you need to (or might possibly someday need to) filter or sort a fetch request based on attribute values, don't use a transformable. They can't be used for either purpose beyond extremely basic stuff like checking to see if the value is nil.
OK, I owe you.
I asked a question without investigating things properly.
The real answer is to understand NSManagedObjects.
Sorry for bothering you
There is no shortage of tutorials on coredata, or questions here on SO about how to get started with coredata, or how to use specific parts.
My question is higher level - how should a larger project be architected with coredata?
Should the project keep most of the functions that deal with managed
objects in a single class?
Should the functions that deal with the
methods be static (I suppose they are called 'class methods') or
instance methods?
Is it ok to pass managed objects into class
methods from different threads? what about if I also supply a
context to the method?
Should I only be doing a single fetch for each entity when the app starts, then doing all of my searches and inserts against the context, or grabbing smaller sets of data from a fetch request as I need it?
As far as the blogosphere goes, it seems like the coredata architectures are the wild west - every man for themselves. Any good design patterns here to follow?
True, although some of you questions are really based on personal preference. I for one will never use a sigleton.
NO and YES. Yes on class to keep the connection to the context and no every controller will request its own data.
Using class methods requires you to either pass the context around or store it in a static. Using a static can cause problems if you need to change the context.
No, each thread should have it's now context. Core Data is not thread save.
To save memory only fetch what is needed, no sense in fetching everything at once.
I would suggest using NSFecthResultsController for filling things like table views.
If you are fetching data and storing it in core data I can really suggest using a separate context for inserting. Cocoanetics has a great article about multiple context setup.
Typically I use Core Data in my applications, but for my current project I don't need data to persist launch to launch.
Because of that, I'm wondering how I should store my data. It's not going to be tens of thousands of items or anything, hundreds at the high end most likely.
I'm still going to create an NSObject subclass to represent each "entry" in the database, but what should I store that in? A simple NSMutableArray that's a property? Should I have a distinct model class? Should I still be using Core Data somehow?
What's the accepted/best practice for a situation like this?
The persistence aspect is only one part of core data. The fetch requests, object graph maintenance and entity modeller are arguably just as important.
If you don't want to persist your data, use the in-memory store type when creating your core data stack.
I would say that if you are familiar with Core Data why dont use it?
But alternatively of course you can stick with NSUserDefault. Atm i'm using the NSCache class.
Good explanation of NSCache and how to use it
Apple's Doc
I would give it a shot if you dont like to use CD for your current Project..
Since you're not worried about persistence, it seems simplest to just use a wrapper around an NSMutableArray (or NSMutableDictionary if indexing is more important that ordering) Since you can apply NSPredicates to arrays you've still got the ability to do very dynamic database style sorting and searching without some of the drawbacks of core data.
Use a wrapper instead of just using an array because that gives you a convenient place to put sorting and searching options, as well as possibly giving you better access to KVO operations.
browsing in some core data pages online i found a tutorial that use an interesting technique, i never seen nor used it before, but actually looks pretty smart.
Instead of working with long methods, with FRC, and so on, they place the results of the fetchResultController in an array, so they can use it to do all the work.
here is the link.
http://www.appcoda.com/introduction-to-core-data/
What do you think are the errors of using this approach? it's a valid one?
It works, but it completely defeats the purpose of the NSFetchedResultsController. The FRC is meant to fetch objects from Core Data in batches, which is much more efficient. If you create an array from all the fetched objects, you will load all those objects into memory at once (if you have a gazillion entities, then this will be a problem). Also if any of your data ever changes (you get notified by the delegate), then you will need to perform the fetch again, then recreate the array yourself.
I would like to know how to manage a big Core Data ManagedObjectModel like this, but with more attributes in every entity. Proyectos(means Projects) and Desarrolladores(means Developers) will be a Table View. The other entities will be only items. I want to manage with singleTon for the fetchedResultController and to control the managedObjectContext
Does anyone knows about some examples like this? Big Models or something? All that I find is with only one entity or two.
Another question is that I am going to get all the data from JSON requests, so I want to know if I had to use NSPersistentStoreCordinator or I should use UIManagedDocument?
This is other example
Thank you.
I recommend using a sigle shared (Singleton) UIManagedDocument to ensure that you have the same UIManagedObjectContext for all the classes in your App.
Example on how to set this up can be found in thos blog:
http://www.adevelopingstory.com/blog/2012/03/core-data-with-a-single-shared-uimanageddocument.html
You can have several NSFetchedResultsController that will use this shared UIManagedObjectContext (from the shared UIManagedDocument).
This is a sample project I did for the Stanford course CS193p on iPhone programming. It uses Core Data with the sigleton I am proposing.
https://bitbucket.org/jcatalan007/cdspot
If you are using CoreData to cache data from JSON, you might want to look at https://github.com/RestKit/RestKit. It will take care of mapping between JSON objects and CodeData objects - potentially saving you a lot of code.
The model you show is not very large; examples in books and courses are deliberately small because they are only intended to teach. Real-world databases are always larger.