Thanks for helping me analyze the situation more carefully.
Yes, I do mean deleting "a managed object of that entity type". (I come from a
modelling background where we commonly used the word "entity" to mean an object
of a particular type/class.)
And yes, deletes are not the problem. You are correct that it is the
consequence of the delete that is the problem.
What happens is two-fold:
1- the predicate is "invalid". It references (as an NSString) an non-existent
project, for example. This in and of itself is not the major problem as you
point out.
2- the invalid predicate breaks the NSPredicateEditor. My
NSPredicateEditorRowTemplate subclass populates its popup button dynamically
based on the current contents of an NSArrayController bound to the entity in
question (e.g., Project). When it tries to match the popup to this predicate it
complains because there is no longer an entry matching the deleted object's
name.
However, following your last suggestion, I think the following should work:
- when a SmartGroup is created, register an observer on its predicate attribute.
- then whenever the predicate is changed:
- parse the predicate to find all of the objects mentioned (by name),
and
- create a bi-directional reference between each object and this
SmartGroup object
- then when attempting to delete the object (e.g. a Project) inform the user
and, if given the go-ahead, clean up all predicates which reference the object
before asking Core Data to delete the object.
----
Martin Stanley
Thinking Ventures
m...@thinkingventures.com
On 2010-07-30, at 10:13 AM, Keary Suska wrote:
> On Jul 29, 2010, at 5:59 PM, Martin Stanley wrote:
>
>>> Even if you could capture a proposed deletion before save, which AFAIK you
>>> can't, you will still have an undo mess. IMHO you best bet is to capture
>>> the situation at the point of editing the predicate, substituting the
>>> deleted item with a placeholder like "<deleted>".
>> I agree, trying to capture the deletion would be an unholy mess.
>>
>> But perhaps I haven't explained the problem clearly enough. The problem
>> arises not when the predicate is being edited, but when entity referenced in
>> the predicate is deleted. I need to find a way to notice this and then to
>> take corrective action.
>>
>> Also, it would be nice to let the user know that the deletion of this entity
>> will invalidate a SmartGroup. Once the model is changed appropriately I can
>> perform this check in response to the user request to delete the entity.
>
> I was assuming that your language use was loose, but do you *really* mean
> deleting an entity, or simply deleting a managed object of that entity type?
> The former would be a horribly bad idea in most cases.
>
> Assuming that you don't mean the above, I still don't think you are
> articulating the problem correctly. Deleting isn't the problem--Core data
> does that just fine. It seems that it is some *consequence* of the deletion
> that is the problem. What is that precisely? That a "smart group" will be
> invalid? Unless you present it otherwise to the user, it is just a predicate,
> and it is just as valid if it doesn't match anything.
>
> But then if the problem is that you don't want this condition to occur
> without user consent--which may be a friendly feature--as long as project
> objects can't be deleted by core data internal processes (such as the result
> of a delete rule), you have complete control over the deletion, so you can
> check it then, before it even occurs.
>
> Keary Suska
> Esoteritech, Inc.
> "Demystifying technology for your home or business"
>
_______________________________________________
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
