I am facing a really weird problem! In my application which is using CoreData, I created a model. When the application ran the database was created. I openend the database using Firefox SqliteManager and added another column to it "ZABOUT" (For some reason the Core Data prefix columns with Z). Anyway, I also populated the ZABOUT column with some data. But now when I retrieve the object from within the app and display the value of ZABOUT it displays null. Any ideas what is going on.
If I set the value from within the iPhone application then it prints out okay.
Core Data and SQLite are separate technologies, and you can't mix them that way. If you want to add another entity, you need to do it through your Core Data model, not through SQLite.
Core Data configures the sqlite file it uses as a backing store with a private schema that is derived from it's data model. Because the Core Data framework is controlling the schema and contents of the .sqlite file, it's best not to think of it as an sqlite file. The fact that SQLite is used is essentially an implementation detail.
More on Core data, and what Core Data is Not. Core Data is not a relational database, and if that's what you're looking for, you might consider just using SQLite directly. XMLPerformance is probably the best sqlite-on-iOS sample.
Related
I use Cocoa's Core Data framework which has the possibility of writing the data to XML via NSXMLStoreType.
For Copy & Paste in my app would I now like to write some core data objects to NSPasteboard and read it from there again. I thought that it should be able to read and write the in-build XML representation. Of course could I create a Codable interface for my core data classes, but I rather reuse the core data implementation.
How can I do this best?
Many thanks in advance!
The problem with this strategy is that the details of the XML store's schema implementation is internal to Apple. If you're going to use the results with another XML store, you should be ok. But I wouldn't expect the XML schema Apple uses to lend itself to being useful outside of that context, as it is written to disk, or depend on it not to change.
You can specify the store type when configuring an instance of NSPersistantContainer by setting its persistentStoreDescriptions property. NSPersistentStoreDescription has a type property, which can be set to NSXMLStoreType.
I have an app which uses Core Data. I have defined the Entities with their respective attributes several times. Now, I pretty much have it finalized, looking like this:
I deleted the old sqlite d/b, re-ran the program which creates a new Sqlite d/b, and it looks like this (using SQLite Database Browser). The areas highlighted in yellow are the ones that don't belong there (IMHO)... how do I clear the old junk out of there when the Sqlite d/b is re-built from Core Data?
The motivation is quite simple.
When you use entity inheritance, Core Data, under the hood, creates a (relational) table that has all the properties for the parent entity as well as its child (or children).
Although this feature is very useful, you should be aware of such a mechanism to avoid performance penalties.
Anyway, you should not work with the db created for you. You should think only in terms of object graph. You will simplify your life.
Hope that helps.
I am new with Core Data and wanted to know if I should use it or not. I want an entity to only have one record which has a bunch of attributes. Should I be using something else or is Core Data fine for this?
For example: I have a user's home entity and it has a bunch of attributes about the house, but I expect the user to have only one home.
You should make your model class to be NSCoding compliant and store it on NSUserDefaults. Using core data to store only one record brings the overhead of the core data stack, and it's a hefty price for only 1 record.
I am a novice in Objective-C; and I could not find any solution in my Books or internet.
My question: What are the most efficient and fastest ways to use already compiled .mom and SQLite db without having the source codes?
Details:
I am trying to connect my small app to the database of another application and use (read-inly) the part of its data. But the task is difficult since that app does not have SDK.
That app has a compiled .mom file and an SQLite database.
I succeeded to programmatically (not using IB) connect to the db using .mom and could manage to get the entities, fill data into the objects re-created by me etc.
But I am doing every step with guesses, trials and errors. Thus the development takes a lot of time and is error-prone.
The most difficult task to dissect is to-many relationships via intermediate tables.
For example: entity "Books" has a relationship to "Authors". Since the sequence of authors matters, there is an intermediate table "authorsNumbered" which contains fields: number, author, book; and the field "number" determines the exact order of authors as they should appear everywhere (important!)
I finally managed to create an ordered array of authors using NSSortDescriptor but it took me whole week to find and guess how to do it!
Would you suggest more efficient ways to deal with compiled .mom rather than the one used by me?
Thanks
If you copy the .mom file and change the extension to .plist you will get a plain text, human readable plist file which you can puzzle out with relative ease.
Create a empty model file say Example.exdatamodeld.
Select it.
In Xcode Editor -> Import and select your mom file.
You can view datamodel inside that mom file.
I'm getting ready to dive into my first Core Data adventure. While evaluating the framework two questions came up that really got me thinking about using Core Data at all for this project or to stick with SQLite.
My app will heavily rely upon importing data from an external source. I'm aware that one can import into Core Data but handling complex relationships seems complicated and tedious. Is there an easy way to accomplish complex imports?
The app has to be able to execute complex queries spanning multiple tables or having multiple conditions. Building these predicates and expressions simply scares me...
Is it worth to take the plunge and use Core Data or should I stick with SQLite?
As I and others have said before, Core Data is really an object-graph management framework. It manages the relationships between model objects, including constraints on their cardinality, and manages cascading deletes etc. It also manages constraints on individual attributes. Core Data just happens to also be able to persist that object graph to disk. It can do this in a number of formats, including XML, binary, and via SQLite. Thus, Core Data is really orthogonal to SQLite. If your task is dealing with an embedded SQL-compatible database, go with SQLite. If your task is managing the model layer of an MVC app, go with Core Data. In specific answers to your questions:
There is no magic that can automatically import complex data into any model. That said, it is relatively easy in Core Data. Taking a multi-pass approach and using the SQLite backend can help with memory consumption by allowing you to keep only a subset of the data in memory at a time. If the data sets can be kept in memory, you can write a custom persistent store format that reads/writes directly to your legacy data format from within Core Data (see the Atomic Store Programming Guide).
Building a complex NSPredicate declaratively is somewhat verbose but shouldn't scare you. The Predicate Programming Guide is a good place to start. You can, of course, also write predicates using a string format, much like a string-formatted SQL statement. It's worth noting that, as described above, the predicates in Core Data are on the objects and object graph, not on the SQL tables. If you really want to think at the level of tables, stick with SQLite and write your own wrapper.
I can't really speak to your first point.
However, regarding your second point, using Core Data means you don't have to really worry about complex queries since you can just pretend that all the relationships are properly established in memory already (Apple's implementation details aside). It doesn't matter how complex a join it might be in a database environment because you really aren't in a database environment. If you need to get the fourth child of the grandparent of your current object and then find that child's pet's name and breed, all you do is traverse up the object tree in code using a series of messages or properties. No worries about joins or anything. The only problem is it might be really slow depending on your objects' relationships, but I can't really speak accurately to that since I haven't actually implemented anything using Core Data (I've just read about it extensively on Apple's and others' websites).
If the data importer from an external source is written based on the same core data model (for the targeted/destination side of the import) - nothing will be conceptually different as compare to using/updating the same data (through the core data stack from your actual application).
If you create the data importer without using the core data stack, make sure you learn well the db schema that would be generated/expected by the core data based model. There is nothing magic there - just make sure you follow how the cross entity relationships are implemented and how entity hierarchies are stored.
I had to create recently a data importer from Access database into the core data based Sqlite store as a .NET app. Once my destination core data model was define, I created a small app that populated the Sqlite store with randomly generated entities (including all the expected relationships). Then, I reverse engineered how the core data actually created the Sqlite store for the model and how it handles the relationships by learning from the generated and persisted data. Then, I implemented the .NET based importer/data-transformer according to my observations. At the end, I got perfect core data friendly data store that could be open an modified from the application that was using the core data stack on Mac OSX.