Core Data, transient properties and saving

  • Hi Guys,

    Has anyone come across this before? I've looked online and I think I
    know the problem but the solution is evading me!

    I have an NSManagedObject that represents a text file, the text itself
    is saved to a text file and the file's attributes are stored in the
    persistent store (much the same way Xcode works).  The file has a non-
    optional, transient property isEdited (default is NO) that gets
    updated to YES when the text is edited and then set to NO when the
    text itself is saved to the locations specified by the file's path
    property.  However if I want to save an individual file and then save
    any changes to the object graph subsequent fetches with the predicate
    @"isEdited == YES" does not return any other edited files.

    So saving the store has turned all my file objects into faults.
    However as all my files are in a source list, after saving one file
    selecting one of the other files I know to be edited and then trying
    to fetch again returns the selected file.  Therefore the fault seems
    to be fired by my tree controller and the isEdited value is correct.

    In practice a user will edit multiple files and then save one of them,
    then try to quit the program which tries to fetch any edited files and
    throw up a dialog asking the user to save all the other edited files,
    but as the other edited files are faults the fetch returns no edited
    files and the program quits.

    How can I work around this?  I could always walk the tree and ask each
    file if they're edited, but a fetch seems cleaner.

    Thanks for any pointers,

    Jon
  • As a summary, you can't fetch or sort against transient properties
    reliably.  They don't exist in the persistent store (database).

    The in memory filtering will apply your predicate to any dirty
    objects to reconcile unsaved changes with the results from the
    persistent store.

    > So saving the store has turned all my file objects into faults.

    Not exactly, the managed objects are marked clean (not dirty) after
    saving.  Since the objects are no longer dirty, the MOC's filtering
    will not post process them for unsaved changes.

    > How can I work around this?  I could always walk the tree and ask each
    > file if they're edited, but a fetch seems cleaner.

    You should probably keep an NSSet of "edited" objects.
    Alternatively, you could make it a persistent property and manage the
    consequences of that.
    --

    -Ben
  • Thanks for the quick reply Ben and your explanation of what's going on.

    I've just re-read the Fetching section of the Core Data Programming
    Guide and its glaring at me not to fetch using transient attributes.

    I appreciate your help.

    Jon

    On 23 May 2008, at 22:32, Ben Trumbull wrote:

    > As a summary, you can't fetch or sort against transient properties
    > reliably.  They don't exist in the persistent store (database).
    >
    > The in memory filtering will apply your predicate to any dirty
    > objects to reconcile unsaved changes with the results from the
    > persistent store.
    >
    >> So saving the store has turned all my file objects into faults.
    >
    > Not exactly, the managed objects are marked clean (not dirty) after
    > saving.  Since the objects are no longer dirty, the MOC's filtering
    > will not post process them for unsaved changes.
    >
    >> How can I work around this?  I could always walk the tree and ask
    >> each
    >> file if they're edited, but a fetch seems cleaner.
    >
    > You should probably keep an NSSet of "edited" objects.
    > Alternatively, you could make it a persistent property and manage
    > the consequences of that.
    > --
    >
    > -Ben
previous month may 2008 next month
MTWTFSS
      1 2 3 4
5 6 7 8 9 10 11
12 13 14 15 16 17 18
19 20 21 22 23 24 25
26 27 28 29 30 31  
Go to today