awakeFromInsert called twice with nested contexts

  • I'm finding that if I use nested managed object contexts,
    awakeFromInsert will be called twice on new objects.

    The first call to -awakeFromInsert happens when I actually create a
    managed object and insert it into the child context. On this call, if
    I break in awakeFromInsert, self's managed object context is the child
    context. The second call happens when I tell the child context to
    save-- but this time, at the awakeFromInsert breakpoint, self's MOC is
    the parent context. I've verified that it's the same object by
    checking the object ID.

    Since awakeFromNib is documented to be called only once in the
    object's lifetime, I'm wondering if this is a Core Data bug or a
    documentation bug. Has anyone else seen this?

    --
    Tom Harrington
    <atomicbird...>
    AIM: atomicbird1
  • On 2011 Nov 16, at 17:16, Tom Harrington wrote:

    > I'm finding that if I use nested managed object contexts,
    > awakeFromInsert will be called twice on new objects.

    > I'm wondering if this is a Core Data bug or a documentation bug.

    I'd say it's a pretty serious Core Data bug.  I've not had an occasion to use nested managed object contexts yet, but I put things in -awakeFromInsert that I only want to happen once.
  • On Nov 20, 2011, at 5:48 AM, Jerry Krinock wrote:

    >
    > On 2011 Nov 16, at 17:16, Tom Harrington wrote:
    >
    >> I'm finding that if I use nested managed object contexts,
    >> awakeFromInsert will be called twice on new objects.
    >
    >> I'm wondering if this is a Core Data bug or a documentation bug.
    >
    > I'd say it's a pretty serious Core Data bug.  I've not had an occasion to use nested managed object contexts yet, but I put things in -awakeFromInsert that I only want to happen once.
    >

    It's certainly not explicitly documented, however a quick scan of the iOS forums finds another 3 developers who've discovered the same thing. Is it really the same object however? It can't be, right, they have different addresses, so Core Data is arguably doing what the documentation says, it's calling awakeFromInsert only once in the object's lifetime, you just have two objects, one in each context.

    What does the object look like when you get the second call? Has Core Data literally just created it in the second MOC and is calling awakeFromInsert on it before (I assume) populating the data on it from the original, or is it already a clone of the first, with properties and relationships set on it? If the former that seems not too inconsistent, new object in new store gets called to set up defaults before the properties you set on it are cloned over, if the second case, that's much harder to deal with (and sounds like a bug)
  • On Nov 16, 2011, at 6:16 PM, Tom Harrington wrote:

    > I'm finding that if I use nested managed object contexts,
    > awakeFromInsert will be called twice on new objects.

    On Mac OS X 10.7 NSManagedObjectContext can have a parentContext.

    Perhaps this would be applicable.

    --Richard
  • On Sat, Nov 19, 2011 at 6:49 PM, Roland King <rols...> wrote:
    >
    > On Nov 20, 2011, at 5:48 AM, Jerry Krinock wrote:
    >
    >>
    >> On 2011 Nov 16, at 17:16, Tom Harrington wrote:
    >>
    >>> I'm finding that if I use nested managed object contexts,
    >>> awakeFromInsert will be called twice on new objects.
    >>
    >>> I'm wondering if this is a Core Data bug or a documentation bug.
    >>
    >> I'd say it's a pretty serious Core Data bug.  I've not had an occasion to use nested managed object contexts yet, but I put things in -awakeFromInsert that I only want to happen once.
    >>
    >
    > It's certainly not explicitly documented, however a quick scan of the iOS forums finds another 3 developers who've discovered the same thing. Is it really the same object however? It can't be, right, they have different addresses, so Core Data is arguably doing what the documentation says, it's calling awakeFromInsert only once in the object's lifetime, you just have two objects, one in each context.

    Actually I don't, so far as I can tell. As I mentioned in my previous
    message, I get the same managed object ID both times. I haven't
    checked the address, but surely if they were different objects they
    wouldn't have the same ID.

    > What does the object look like when you get the second call? Has Core Data literally just created it in the second MOC and is calling awakeFromInsert on it before (I assume) populating the data on it from the original, or is it already a clone of the first, with properties and relationships set on it? If the former that seems not too inconsistent, new object in new store gets called to set up defaults before the properties you set on it are cloned over, if the second case, that's much harder to deal with (and sounds like a bug)

    The object appears the same both times-- a new object with no
    properties or relationships set.

    --
    Tom Harrington
    <atomicbird...>
    AIM: atomicbird1
  • On Sun, Nov 20, 2011 at 2:34 PM, Richard Somers
    <rsomers.lists...> wrote:
    > On Nov 16, 2011, at 6:16 PM, Tom Harrington wrote:
    >
    >> I'm finding that if I use nested managed object contexts,
    >> awakeFromInsert will be called twice on new objects.
    >
    >
    > On Mac OS X 10.7 NSManagedObjectContext can have a parentContext.
    >
    > Perhaps this would be applicable.

    That is specifically what I meant when I mentioned nested contexts--
    one context whose parent context is another context.

    --
    Tom Harrington
    <atomicbird...>
    AIM: atomicbird1
  • On Nov 27, 2011, at 16:49 , Tom Harrington wrote:

    > Actually I don't, so far as I can tell. As I mentioned in my previous
    > message, I get the same managed object ID both times. I haven't
    > checked the address, but surely if they were different objects they
    > wouldn't have the same ID.

    You're wrong about that. Different objects will of course have different pointers, but that's the most you can say.

    The object, and hence the object pointer, is specific to a managed object context. The "object ID" is an attribute of the persistent store, and is independent of the MOC.

    Core Data has no word for the object as it exists in the persistent store, except perhaps informally "row". The "object ID" is really a "row ID".

    > The object appears the same both times-- a new object with no
    > properties or relationships set.

    That makes sense. 'awakeFromInsert:' allows you to populate object properties, not row properties.
  • On Sun, Nov 27, 2011 at 6:09 PM, Quincey Morris
    <quinceymorris...> wrote:
    > On Nov 27, 2011, at 16:49 , Tom Harrington wrote:
    >
    > Actually I don't, so far as I can tell. As I mentioned in my previous
    > message, I get the same managed object ID both times. I haven't
    > checked the address, but surely if they were different objects they
    > wouldn't have the same ID.
    >
    >
    > You're wrong about that. Different objects will of course have different
    > pointers, but that's the most you can say.
    >
    > The object, and hence the object pointer, is specific to a managed object
    > context. The "object ID" is an attribute of the persistent store, and is
    > independent of the MOC.

    If they're different objects then I'm getting duplicates, which is at
    least as much of a bug and possibly more so. What I observe is that if
    I add 10 objects, I get 20 calls to awakeFromInsert, 10 for the child
    context and 10 for the parent. But, there are only 10 unique managed
    object IDs. It might be that I just happen to be getting the same IDs
    for two completely different sets of objects, but there shouldn't be
    two sets in the first place.

    --
    Tom Harrington
    <atomicbird...>
    AIM: atomicbird1
  • On Nov 27, 2011, at 20:50 , Tom Harrington wrote:

    > If they're different objects then I'm getting duplicates, which is at
    > least as much of a bug and possibly more so. What I observe is that if
    > I add 10 objects, I get 20 calls to awakeFromInsert, 10 for the child
    > context and 10 for the parent. But, there are only 10 unique managed
    > object IDs. It might be that I just happen to be getting the same IDs
    > for two completely different sets of objects, but there shouldn't be
    > two sets in the first place.

    Objects are specific to a managed object context, so it's correct that there would be 20 objects, and it's correct that there would be only 10 object IDs.

    For any given "row" in the persistent store, there will be one object *per managed context* in memory. The set of objects that correspond to the row all have the same object ID -- that's what object IDs are for. All of the numbers you're quoting are consistent:

    1 persistent store
    2 managed object contexts
    10 rows to be inserted in the persistent store (when the MOCs are eventually saved)
    10 object IDs, one per row
    20 object instances, one per row per managed object context
  • On Nov 27, 2011, at 9:23 PM, Quincey Morris <quinceymorris...> wrote:

    > On Nov 27, 2011, at 20:50 , Tom Harrington wrote:
    >
    >> If they're different objects then I'm getting duplicates, which is at
    >> least as much of a bug and possibly more so. What I observe is that if
    >> I add 10 objects, I get 20 calls to awakeFromInsert, 10 for the child
    >> context and 10 for the parent. But, there are only 10 unique managed
    >> object IDs. It might be that I just happen to be getting the same IDs
    >> for two completely different sets of objects, but there shouldn't be
    >> two sets in the first place.
    >
    > Objects are specific to a managed object context, so it's correct that there would be 20 objects, and it's correct that there would be only 10 object IDs.

    To clarify: if you had two nested MOCs that shared the same parent MOC, how would you plan on editing an object in Nested Context A as well as in Nested Context B if there *weren't* two separate NSManagedObject instances with the same object ID, each associated with a different context?

    --Kyle Sluder
previous month november 2011 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        
Go to today