I'm beginning to use Core Data and I'm trying to get a solid understanding of how it would work in my case. I'm building an iPad photo album app that will allow users to filter their results based on keywords and a couple of other attributes associated with each photo. The attributes would be basic stuff like orientation and whether its color or not. Keywords will be based on a set of defined values that the user will have to choose from.
Here's a rough outline of what I have in the Core Data Model so far:
Entities (attributes):
Photos (id, title, desc, file path)
Keywords (id, name)
Since a photo can have multiple keywords associated with it, do I create a relationship from 'Photos' with a destination of 'Keywords' and make it a -to many relationship? Is that correct/crazy/completely wrong? How would I go about adding/fetching records for that relationship?
If the Keywords are defined and the user can choose them from a defined list, I wouldn't have used an entity Keyword. Tip always use singular names (Photo, Keyword). I would have the keywords in a plist and the user chooses a few, you could then create a comma separated string to save as a property on Photo. As Joseph mentioned, you want to subclass NSManagedObject and I would then add a method that receives a string (keyword) and returns a BOOL indicating if that keyword was part of the comma separated keyword values on the Photo property
This is correct. There are several approaches to accessing this, but the most straight-forward way is to generate NSManagedObject subclasses (Editor->Create NSManagedObject Subclass...). When populating these the Photo entity, the Keyword relationship will be populated in the property called keywords.
Related
I have a object called photo with an attribute called multitag of type array. For ex photo A has tag desk, photo B has tag chair and photo C has tags desk,chair. If user searches for desk, A is returned. If user searches for chair B is returned. If user searches for desk chair C is returned first folllowed by A and B. How do you do that using PFQuery?
I don't think I would do this particular type of data relationships using tags in arrays. You are better off using pointers or relations for this task.
For example:
the Photo class has a column tag which is a ParseRelation column type that points to the Tag class. For each photo in the Photo class you will add as many Tag objects to the Photo.tag column as you wish. This makes it very easy to query for and it is scales better than using arrays.
Here is the Parse guide on using Relations
I recently asked this question about how best to retrieve and display in a tableview the titles my FRC is using for section headers.
Following a line of research suggested by #Mike Pollard in the second answer to my question, I ran across this question and was immediately struck by the similarity to my situation, and by the 4th answer, posted by #aroth.
Aroth's approach certainly appears sound, and I've created a new Category entity. Specifically, Category has a to-many relationship with Item, and Item has a to-one relationship with Category. However I'm having trouble understanding one aspect implicit in his proposed solution, and, more fundamentally, in this relationship:
In my case, both Category(s) and Item(s)--"Item" is called "ListActivity" in my case, but "Item" will do for illustration purposes-- will be named via two corresponding user input fields, which seems like it could result in multiple entries of the same name in the Category list.
My question:
How can I ensure that when I fetch a list of Categories that I get a singular instance of each category, i.e., one category per row in the tableview, with no repeats? Will Core Data automatically assign each new incoming Item to a singular instance of the appropriate Category via the relationship? Or will it somehow test for and winnow the list down to one entry per Category name upon receiving the fetch request? Or must the filtering be done with a predicate in the fetch request?
Thanks!
Core Data will do what you tell it to. This sounds like an issue related to you creating content in your data store rather than an issue with the FRC and table view. It's your responsibility to search for and reuse existing objects rather than creating duplicates and adding them to the store - indeed, only you (your code) knows what constitutes a duplicate.
So, basically, as you create new items, use a fetch request and predicate to find the suitable existing category (or suggest categories based on partially entered names). Then, either connect to the existing category or create a new one.
I am building an app around CoreData and have bumped into a dilemma. Hopefully has a simple solution.
I have an entity, 'Equipment'. Each equipment object has a name and type. When selecting a type depending on the selection, I need to add more attributes to that entity, but only to that object.
So if I have an equipment object of type bowl. I want to add the attribute containsMilk for example. Whereas if the type is knife, I want to add the attribute isBreadKnife.
Any tips on how to do this? As you can see, not every equipment object will necessarily have the same attributes and different types require unique ones.
How can I achieve this? Thanks.
I'll try to be short and clear with this question.
We have an asp.net mvc app that uses entity framework 4.
Our business model is relatively straightforward:
We have an object (which corresponds to a table) called Photo(s).
That photos table has a handful of columns that match up to properties on the object.
Description,Title,Date etc.
It also has a number columns that reference foreign keys for other tables:
AuthorId,LicenseId etc...
The author and license tables are complex in their own right, with multiple fields (Title,Summary,Date etc.)
I have multiple clients using this application to view their photos. I would like each client to dictate what fields they see when viewing the photos, as well as what fields they see when editing those fields.
My thought is to have tables setup saying client-a should see Field1,Field2 and Field3 when viewing their photos - and client-b should see Field1,Field4 and Field5. But some of these fields are not simply columns in the main photos table, they may be fields in a child table. so Field1 might be: Table.Photos.Title -> which corresponds to an object as: Objects.Photo.title...
but Field3 might be: Table.Licenses.LicenseSummary -> which corresponds to an object as: Objects.Photo.License.LicenseSummary
I'm trying to figure out the methodology that we would use to have a very data driven environment so in the DB I can say, display this object/property (for viewing or editing) and then it would know how to map to whatever table it needs to pull that information. also, during editing... give it some way to pull a list of available values if it is that type of property, and not just a text field.
I'm looking for an example of what this might involve, our model is actually more complex than this, but this is just an idea of what we are trying to accomplish. I don't know if what I'm trying to do is normal, perhaps it involves reflection? This is a new area for me.
If the clients are defining their own custom fields, I would simply give them a Key/Value pairs table.
PhotoID FK
Key string
Value string
Display bool
Note that this essentially amounts to EAV, which comes with its own set of difficulties.
If it's just about permissions on existing fields, you need to capture that information:
PhotoID FK
ClientID FK
FieldName string
Display Bool
You can use this information to inhibit the display of fields in the View. The easiest way to do that would be to use a loop in the View itself, writing the field to the output only if Display is set to true.
I am running a Rails 3.2 app with a MySQL DB and I want to build a model which is kind of a dynamic collection for example I will call it Album.
An Album should contain multiple instances of another model for example I call them Items but I don't want to relate them only statically with a one-to-many join-table.
It should be possible also to define criteria like:
Album contains Items from start-date to end-date
Album contains Items where flag XY is "foo"
..
these criteria / parameters should be stored persistently in the database. Items should not be linked once, new Items should be attached to an album if they match the parameters
Number of parameters should be flexible e.g multiple time-ranges for an Album should be possible. So i think about an extra table which stores the relation between an Album and the matched time-ranges.
What would be be the best / most performant way to implement way this and make all Items within an Album accessible over a simple album.items call?
How/where should I store the parameters for the dynamic linking?
I think you could create an ItemSet class, since each Album can have multiple sets of criteria. ItemSet could have various subclasses using single table inheritance (or you could possibly achieve this kind of behavior another way; see here), and you could define the items method in each subclass depending on which kind of ItemSet it was (based on date, flag set, etc.). album.items would be the union of the items in each of album.item_sets.