Re: Enforce Min Count in Core Data To-Many relationship
Re: Enforce Min Count in Core Data To-Many relationship
- Subject: Re: Enforce Min Count in Core Data To-Many relationship
- From: mmalcolm crawford <email@hidden>
- Date: Sun, 11 Jun 2006 09:55:51 -0700
On Jun 11, 2006, at 3:34 AM, Erik Buck wrote:
I have an entity called Plan that has a To-Many relationship
property called "pages".
There must always be one or more Pages per Plan, so the in the X-
Code data data model, I have set the Min Count field of the "pages"
relationship property to 1.
Interestingly, setting the Min Count seems to have no effect at
all. I expected that Core Data's built in relationship validation
would enforce the specified Min Count and not for example let the
last Page relationship be deleted.
There is nothing to disallow an in-memory object from becoming
inconsistent on a temporary basis. The validation constraints are
applied by Core Data only on a "save" or upon request (you can invoke
the validation methods directly as and when you wish). If this were
not the case, it would amongst other things force a particular
workflow in the end-user (in this case you would have to create a new
"Page" object before deleting the last one) -- this may not be a
particular problem here, but may well be in other applications. This
also underpins the idea of a managed object context representing a
"scratch pad" -- in general you can bring managed objects onto the
scratch pad and edit them however you wish before ultimately either
committing the changes or discarding them. (Consider also the
degenerate case when a Plan object first comes into being -- it
cannot have any associated Page object...)
Similarly, I expected that a fetch of a Plan that has zero pages
would produce an error. In fact, it silently succeeds.
Again, when an object is fetched its values are simply populated from
the store (directly, using setPrimitiveValue:forKey:). If this were
not the case, then if you add validation constraints to your model or
model object class after a given store had been saved, you might find
it difficult to open the store. [*If* the fetch here refers to
retrieving the object from a persistent store, I assume that in this
case you are opening an old store created before the constraint was
added? Otherwise it's not clear how you would have saved the Plan?]
Is there any way for me to get Core Data to enforce the rule that
there should be at least one Page for every Plan ?
Not in the way I think you mean. "How to validate is a model
decision, when to validate is a UI decision" (MP)...
Is there some code I need to write to enforce this ?
... you should invoke the validation method (validateForUpdate:) as
and when you deem it appropriate.
If you want to ensure that just after a new Plan object is created a
new Page object is created for it, you could implement a suitable
awakeFromInsert method.
- (void)awakeFromInsert
{
[super awakeFromInsert];
NSManagedObject *newPage =
[NSEntityDescription insertNewObjectForEntityForName:@"Page"
inManagedObjectContext:[self
managedObjectContext]];
[newPage setValue:self forKey:@"plan"];
}
Have I completely misunderstood the Min Count property of To-Many
relationships ?
I don't think you've *completely* misunderstood it, but you've
ascribed it greater power than it in fact has.
A similar issue has come up recently. Please could you file a
documentation enhancement request. I think this page:
<http://developer.apple.com/documentation/Cocoa/Conceptual/
ModelObjects/Articles/moValidation.html>
needs to be expanded to cover the subject -- perhaps there also needs
to be an article that is specific to Core Data?
mmalc
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden