Re: Core Data Questions--Relationships, UUIDs, and Dirty States
Re: Core Data Questions--Relationships, UUIDs, and Dirty States
- Subject: Re: Core Data Questions--Relationships, UUIDs, and Dirty States
- From: Keary Suska <email@hidden>
- Date: Mon, 27 Oct 2008 16:34:08 -0600
On Oct 27, 2008, at 2:55 PM, I. Savant wrote:
1. Confirmation clarification: do I understand correctly, considering
typical RDBMS data integrity rules, that for most to-one
relationships, I
would set the delete rule to "no action", since deletion of the
"many" item
should not effect the "one" item?
Impossible to generalize, but generally - :-) - you'd want "nullify"
and not "no action". This is because you've most likely taken
advantage of the "inverse relationships". This means that (using the
Department / Employee example), when you remove an Employee from the
Department's "employees" set, you also want to tell the employee that
its department is nil.
Doing nothing in this case will leave your object graph in an
inconsistent state. If you have a good reason for this, knock yourself
out, but if you can't name it, you probably don't have it.
Well, I am looking at just delete cases, but as long as Core Data
won't nullify the to-many relationship until all the "many" objects
are deleted, then it seems safe to nullify. I just wasn't sure if that
was a correct assumption.
2. How do I best implement custom UUIDs for relationships (as a
property to
an entity)? I thought I saw this come up some time ago but I can't
seem to
find the discussion.
I'm not sure I understand your question ... do you want a UUID to be
the name of a relationship or do you just want a property that is a
UUID? What is your goal? Are you looking to solve a cross-store
relationship problem?
My persistent store is not supported, the source RDBMS has legacy
primary keys that have to be maintained, and I need to know when the
key changes so I can maintain referential integrity. If I can use my
own keys for UUIDs, I can let CD take care of that. Otherwise I have
to do all that myself. Trying to determine which one is easiest and
least error-prone.
3. How can I, in a bindings-compliant manner, report the "dirty"
state of an
NSManagedObjectContext? I know I can be notified when the context has
changed, and when the context has saved, but what about when the
context has
been rolled back or changes undo-ed?
Isn't an undo just another change? It's setting properties and
relationships back to the way they were, but the key is the word
"setting".
Well, if you undo back to the original state, the MOC reports NO for -
hasChanges. I basically want the same -documentEdited behavior that
NSPersistentDocument gives, without using NSPersistentDocument.
4. Does anyone have recommendations on how I can maintain the
"dirty" state
of a single NSManagedObject? I don't figure there is anything built
into CD
for this.
In a document-based or non-document-based application?
Non-doc based. Basically I just want the documentEdited feature I
describe above. I really just need to know on a per-MO basis, but if
that is not practical, I can probably work with just knowing the MOC's
state.
Thanks,
Keary Suska
Esoteritech, Inc.
"Demystifying technology for your home or business"
_______________________________________________
Cocoa-dev mailing list (email@hidden)
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:
This email sent to email@hidden