Databases
StackOverflow2013
Postsdbo
POCoreData user defined database structure?
 

Note that there are some explanatory texts on larger screens.

plurals
  1. POCoreData user defined database structure?
    primarykey
    data
    text
    <p>So, I've just started working on an iOS inventory app, which I'd like to be pretty flexible. What I want is for the user to be able to define a product category, and then its degrees of freedom, i.e. color, size, image, style, etc. I know I could accomplish this by designing a data model which includes these attributes already, but the user may not always need each one and (more troubling) may need other attributes which I hadn't thought of (like material, or brand). Is there some way to build this kind of flexible data model using CoreData? I'm sure I could do it using plists, but I want to take advantage of iCloud and NSFetchedResultsController, not to mention predicates and so forth.</p> <p>Is this not even something that can be realized using a database? Now that I'm looking at the problem, it seems that maybe I'll be too limited by the enforced structure... What if a user changes the attributes after having already added records? Will I have to handle migrating the store? Ugh.</p> <p>...</p> <p>Ok, here's another approach, maybe somebody can comment on if this is crazy or not. I got to thinking, all of the properties a user might add are basically of the same type -- they have a string tag (the name of the property, e.g. 'color') and a series of string values (e.g. 'red', 'charcoal', 'blue', etc). So why not make these relationships, instead of attributes, of the entity? So, now I've got three entities in my object model: <code>MerchCategory</code>, which is the type of merchandise we're talking about, <code>MerchItem</code>, which is an individual item in the inventory, and <code>Dimension</code> which is a quality that an item may have. </p> <p><code>MerchItem</code> has a <code>sku</code> attribute, and a many-to-many relationship to <code>Dimension</code>, as well as a many-to-one relationship to <code>MerchCategory</code>. </p> <p><code>Dimension</code> has <code>name</code> and <code>value</code> attributes, and <code>categories</code> and <code>items</code> many-to-many relationships.</p> <p>Is this a plausible schema? It seems to me that I'll be able to query for each dimension by looking at their names, and get counts of each configuration by looking at their values... And the user will be able to add new ones without mucking about with NSEntityDescription. Thoughts?</p>
    singulars
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. PTQuestion
    1. USsamson
    1. USsamson
    plurals
    1. PL
      singulars
      1. LTLinked
    1. PL
      singulars
      1. LTLinked
    1. This table or related slice is empty.
    1. PO
      singulars
      1. PTAnswer
    2. PO
      singulars
      1. PTAnswer
    3. PO
      singulars
      1. PTAnswer
    1. VO
      singulars
      1. POCoreData user defined database structure?
      1. This table or related slice is empty.
      1. VTUpMod
    1. COI don't see why it wouldn't work that way. In fact, it seems like a great way to utilize the power and flexibility of the core data framework! I would just make sure you set up your deletion methods with care. It's very easy to end up with either dangling entities with no remaining relationships or cascading deletes that take out other entities when they are deleted. Good luck!
      singulars
      1. POCoreData user defined database structure?
      1. USJiuJitsuCoder
    2. COcool, thanks! I'll post an answer when I get it up and running.
      singulars
      1. POCoreData user defined database structure?
      1. USsamson
 

Querying!

 
Guidance
A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload