1

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.

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.

...

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: MerchCategory, which is the type of merchandise we're talking about, MerchItem, which is an individual item in the inventory, and Dimension which is a quality that an item may have.

MerchItem has a sku attribute, and a many-to-many relationship to Dimension, as well as a many-to-one relationship to MerchCategory.

Dimension has name and value attributes, and categories and items many-to-many relationships.

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?

samson
  • 1,152
  • 11
  • 23
  • I 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! – JiuJitsuCoder Apr 14 '13 at 22:54
  • cool, thanks! I'll post an answer when I get it up and running. – samson Apr 15 '13 at 01:22

4 Answers4

1

See How to add attributes to an existing Core Data entity (object) programmatically?.

You're biting off an extremely large task. It can be done. FileMaker is doing it with FileMaker Mobile and Bento for iPad. But I suspect they have substantially more people to devote to the products.

Community
  • 1
  • 1
Hal Mueller
  • 7,019
  • 2
  • 24
  • 42
  • Awesome. So I guess I can't get this finished over the weekend... That link is helpful, I'll see how much ground I can cover. I guess the basic problem is the migration, really. – samson Apr 14 '13 at 02:36
0

I think you will need to programmatically add entities to your NSManagedObjectModel, using NSEntityDescription, and NSPropertyDescription to add properties to your entity. I am not sure how migration would work.

J2theC
  • 4,412
  • 1
  • 12
  • 14
0

As long as you don't need to fetch by those attributes, you could write the code to add and subtract custom attributes, store them in an nsarray and bundle them all up into an nsdata and store that in core data. You could simply create an entity with as many fixed attributes as you need to be able to sort and fetch by and store the rest in one nsdata attribute.

JiuJitsuCoder
  • 1,866
  • 14
  • 13
  • Yeah, I thought of that. Unfortunately, I DO need to fetch by them, that's kind of the whole point. If I was gonna use NSData packaging like that, I might as well put the whole thing in a plist, I think. – samson Apr 14 '13 at 02:33
0

I'm working on something similar and I'm thinking about creating a new core data class called "Properties", so I can set my objects to have a "relationship to many Properties". Each Property would have core data string-type attributes: "attribute", "type" and "value".

I think that should give enough flexibility to add product properties in the fly. If I happen to implement this, I will post it here

Lucas Chwe
  • 2,578
  • 27
  • 17