Databases
StackOverflow2013
Postsdbo
PO
 

Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>Based on your question and your comments, you are:</p> <ul> <li>Using a single managed object on multiple threads.</li> <li>Not taking any precautions to deal with the fact that <code>NSManagedObjectContext</code> is not thread safe.</li> </ul> <p>As a result, you are getting weird, confusing crashes.</p> <p>This is exactly what one would expect in this situation. Using a managed object context on more than one thread without taking precautions is essentially a recipe for crashes and confusion. These crashes may not make a lot of sense, because you're corrupting the context's internal state.</p> <p>If you want to use a context on more than one thread, you <em>must</em> use one of the queue confinement options (<code>NSMainQueueConcurrencyType</code> or <code>NSPrivateQueueConcurrencyType</code>) and then you <em>must</em> put all code that uses the context or any object fetched from them in a <code>performBlock:</code> or <code>performBlockAndWait:</code>. (Exception: if you use <code>NSMainQueueConcurrencyType</code> and you know your code is on the main thread, you may just use the context directly). You might also use your own locking mechanism via something like <code>NSLock</code>, but come on, threading is already hard enough for most people.</p> <p>It's generally better to use one context per thread, either as parent/child contexts or as independent contexts, but the approach above also works.</p> <p>If you've actually managed to save bogus objects as a result of this, the only real recourse is to fetch those objects and either fix them up or delete them. How to identify these objects depends on your data model-- there's no universal test for "is this object crap?". Any checks depend on what your app considers to be correct.</p>
    singulars
    1. This table or related slice is empty.
    1. PO"Core Data could not fulfill a fault" for objects that were created in the appDelegate managedObjectContext on the main thread
      singulars
      1. PTQuestion
    1. PTAnswer
    1. This table or related slice is empty.
    1. USTom Harrington
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. PO"Core Data could not fulfill a fault" for objects that were created in the appDelegate managedObjectContext on the main thread
      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
    1. COThanks Tom. You are right on. It was actually a mistake made very late one night when I was really tired. I NEVER intended to use multiple threads :( So when I fetch the objects, is there a way to tell that they were created on the background thread vs. the main thread? Otherwise how do I know they are bad, since I created them with all of the data that I want them to have? Also - what about those objects that were NOT created on the background thread - is it normal that I am getting this error for them too, simply because I have royally screwed up ALL OF MY USERS' DATA??
      singulars
      1. PO
      1. USSAHM
    2. COAnd - could the mistake I made also yield crashes with the error:'Illegal attempt to establish a relationship between objects in different contexts'
      singulars
      1. PO
      1. USSAHM
    3. COThe objects don't record what thread they were created on. That's not relevant to a data model (or shouldn't be). Like I said, you'll have to figure out what differentiates "good" from "bad" data according to your app's needs, and use that. They're not bad unless they contain bad data, but only you can say what data is bad. As for other errors, once you start corrupting your context, confusing or nonsensical errors are not much of a surprise.
      singulars
      1. PO
      1. USTom Harrington
 

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