I am new to the Core data and I am a bit confused about how to store a part of the object in another entity...
I have only list of location to be inserted to the "Locations" entity and later recently visited place will be stored...
my question is that can I load Locations entity without providing "RecentlySearched" attribute (relationship inverse)
if not how can i do it?
If the relationship is marked as "optional" (which is the default in the Core Data
Model editor) then you don't have to provide a value.
The value of that property will be nil until you establish a relationship to a
"RecentSearch" object.
Related
Let's say I have one entity "Person" with many attributes and one relationship "shoes" to another entity "Shoe".
The "Person" entity has thousands of "Shoe"s. I have sometimes the need to retrieve just the attributes of this person but I don't need to download all the shoes.
Is it possible to fetch only a "Person" without its relationship "Shoe"?
And consequently, is it possible to fetch the relationship "Shoe" once we already fetched the "Person"?
What you are describing is how Core Data works by default. If you use a fetch request to get a Person, then the returned object's shoes property is a “fault”. A fault is an empty shell. When you first try to access a fault's contents (its properties or, in the case of a collection, its member objects), the fault “fires” by loading its contents from the database.
Read about faults in the Core Data Programming Guide.
would like to ask for the community's suggestions.
I need a persistent store in my iOS app.
I have considered Core Data and SQLite and both are not ideal for the following reasons.
Core Data:
unable to model certain object relationships, such as Object A has a one-to-many relationship with NSString.
//Added:
unable to model a Dictionary(or map) as an attribute for a one-to-one relationship. i.e. Object A has a one-to-one relationship to Object B (and Object B behaves like a dictionary)
SQLite:
poor interface for schema management
no clean and elegant solution for data migration between schema versions
//Added:
unable to model a Dictionary(or map) as an attribute for a one-to-one relationship. i.e. Object A has a one-to-one relationship to Object B (and Object B behaves like a dictionary)
the persistent store has to be able to support search. If anyone can suggest ways to circumvent the problems, that would help too.
Based on your limited description, Core Data would work just fine. Core Data can easily do one to many relationships. No matter what technology that you use, you still need table to table (SQLite) or Object to Object (Core Data) relationships. Nothing is going to give you an Object to String relationship.
You can do Object A to Object B where Object B has only one property which happens to be a string.
Is it possible to restrict a Core Data entry to a single attribute? For example, let's say I have this entity:
Entity
Attribute: name
and there are multiple Entity objects that can be added to the database via a one-to-many relationship. Can I restrict the data entries so that only Entity with different name attributes can be added? I don't want to query the data base every time something is added, because that would cause a performance impact when the database gets larger.
Thanks!
No, you can't.
For now I would have the following ideas.
1 - If the attribute is a string, you should make it as a canonical form (a plain text without accents, etc.). Then you can search with predicates like startsWith or endsWith.
2 - You could add another attribute in entity that you use as a hash value. That hash will be generated when you insert a new object. When you insert a new value, you will check against value.
3 - Indexing the attribute to improve performances.
Core Date cannot check automatically for duplicate values, so you have to check first
if an object with a given value exists before inserting a new one.
If you have to insert many objects, then it is more efficient to fetch all objects having
values from the new list first instead of many fetch requests.
This is described in "Implementing Find-or-Create Efficiently" in the "Core Data Programming Guide".
I have a bunch of code that sets Core Data relationships via the inverse instead of the "addWhateverObject" methods. This usually works well in all of my applications, but I have one app where the relationships are being lost when the NSManagedObject context is being saved.
My question is setting a relationship in Core Data via the relationship's inverse valid or do you have to use the accessor methods to add objects to the relationship?
Thanks!
Yes, using the inverse is valid. Core data does all of the appropriate updating for you when you do that. See the comments on this question Core Data To-Many Relationship Creating Duplicates When Adding Object to Parent Entity
I have 3 tables in my core data tables.
Item table: items, which has an ID column and a connection to a properties table.
Properties table: it has a propertyValue column and a connection to item table and a connection to property table.
Property table: it has a propertyName column and a connection to properties table.
The property table contains a propertyName called "price".
The properties table contains a propertyValue "20" for the property "price".
Do you think I can sort the Items table by price?
I am using a NSFetchedResultsController and I am creating a NSFetchRequest for it.
I have tried to write a NSSortDescriptor with a comparator block object for the NSFetchRequest. It isn't working. After this I tried to write a NSSortDescriptor without any selector or block object, I just setup a key called "dealPrice" and created a category on the Item managed object with a method called - (NSString *)dealPrice. It wasn't working neither.
Do you know any other method? Or do you know the solution?
You've obviously got a bad case of SQL fever. Your trying to treat Core Data like an SQL wrapper and that is messing everything up.
Core Data is not SQL. Entities are not tables. Objects are not rows. Attributes are not columns. Relationships are not joins. Core Data is an object graph management system that may or may not persist the object graph and may or may not use SQL far behind the scenes to do so. Trying to think of Core Data in SQL terms will cause you to completely misunderstand Core Data and result in much grief and wasted time.
A Core Data datamodel should not be configured depending on the needs of the UI or any other non-data requirement. Instead, it should accurately model/simulate the real world objects, events or conditions that the app deals with.
In this case, you are modeling:
A type of property that has a name and a price.
An item denoted by an id of some kind
A relationship between one or more particular property instances and one or more instances of item.
Therefore, your data model only needs two entities connected by a relationship. You don't need a "join" because the relationship handles the connection between the two entities automatically.
The simplest model has just a one-to-one relationship:
Item{
id:string
property<-->Property.item
}
Property{
name:string
price:number
item<-->Item.property
}
If each Item object can have several associated Property objects then you would have:
Item{
id:string
properties<-->>Property.item
}
Property{
name:string
price:number
item<<-->Item.properties
}
If each Property object can have several associated Item objects:
Item{
id:string
property<<-->Property.items
}
Property{
name:string
price:number
items<-->>Item.properties
}
How you configure your sort descriptors depends on the details of the relationships and which entity's objects your tableview will display.
What I would first recommend is to stop thinking about CoreData like a database. It is NOT a database. The things you call "tables" are actually Entities. Think of them as objects, that have properties and relationships to other objects. Think about making your data model as simple as possible. Do not try to optimize your structure for database performance etc. The actual backing schema is not under your control.
With that in mind, from what you've posted about your data model, it seems like you should be able to collapse into at least 2 entities instead of 3 (perhaps 1 but not sure without seeing your entire data model). Then, you should be able to do a simple fetch on the Items entity with a predicate that sorts on a property of it's related object.
It sounds like your real object model is and entity named Deal with an attribute named "price".