Databases
StackOverflow2013
Postsdbo
PO
 

Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>I also ran into this specific unrecognized selector problem - that <code>beginningOfDocument</code> was being called on my (subclass of) <code>NSManagedObject</code> instance in iOS5.x. The problem looks to be fixed in iOS6 though. I also verified that NSZombies gave me nothing, even though it certainly seemed like the right intuition.</p> <p>The unrecognized selector exception was thrown during a <code>valueForKey</code> lookup on our managed object, so it's worth looking at the stack trace to see if this is where the exception is thrown for you as well.</p> <p>In our case, the "broken" key was <code>fullText</code>, the name of one of our attributes. Changing the name eliminated the problem. My guess is that the name caused an error in the underlying sqlite query (I didn't think fulltext was a keyword, but maybe for the full text searching in sqlite?), and perhaps the query arguments are better sanitized in iOS6.</p> <p>You can find out what key/attribute name is broken with this little cheat: Override your <code>valueForKey:</code> method temporarily to NSLog and then just call the superclass version and return it. Even though the docs say not to override it (which we're only doing for a moment to find the offending attribute), this is ok since we're just overriding and then calling the superclass implementation.</p> <pre><code>// Don't forget to remove me after the bug is fixed! - (id)valueForKey:(NSString *)key { NSLog(@"Finding value for key: %@", key); return [super valueForKey:key]; } </code></pre> <p>Then when you run again, you'll see the last call to <code>valueForKey:</code> before the crash and know what attribute name is broken.</p> <p>If you're still having trouble sorting out which was the unsuccessful lookup, you could go with the more verbose:</p> <pre><code>// Don't forget to remove me after the bug is fixed! - (id)valueForKey:(NSString *)key { NSLog(@"Finding value for key: %@", key); id retVal = [super valueForKey:key]; NSLog(@"Success for key: %@", key); // or print retVal for fun return retVal; } </code></pre>
    singulars
    1. This table or related slice is empty.
    1. POCorruption of NSManagedObject-derived objects when property is accessed
      singulars
      1. PTQuestion
    1. PTAnswer
    1. This table or related slice is empty.
    1. USKelly
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. POCorruption of NSManagedObject-derived objects when property is accessed
      singulars
      1. PTQuestion
    1. This table or related slice is empty.
    1. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    2. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTAcceptedByOriginator
    3. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    1. COCongrats on tracking that down. `fullText` was all over the place in our Core Data model. Unfortunately, it's going to be hard to verify since that revision never got committed because of the crashes, but based on your data, it really looks like the field name was the issue. Marking this as the answer.
      singulars
      1. PO
      1. USdandan78
    2. COAwesome - I'm glad the post at least helps resolve some mystery! Thanks for marking it.
      singulars
      1. PO
      1. USKelly
    3. COThanks Kelly for this post. We had exactly the same `unrecognized selector` crash with the same `beginningOfDocument` method call. This crash happened inside the RestKit framework that we use. So it took some time to figure out that is has something to do with KVC and iOS5 and not with RestKit. Thanks to your post we got pointed into the right direction and found a `fullText` in our CoreData model as well. Problem solved.
      singulars
      1. PO
      1. USStefan Arn
 

Querying!

 
Guidance
A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload