Databases
StackOverflow2013
Postsdbo
PO
 

Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>Contrary to what I assumed in above comment, the same effect can happen if a <code>sectionNameKeyPath</code> is specified to create table view sections (I could reproduce this with a test program).</p> <p>When the app is started the first time, the following happens:</p> <ol> <li>A persistent store file "appname.sqlite" is created.</li> <li>A fetched results controller for the table view is created with the <code>cacheName</code> parameter set, so that a section cache file is created. At this point, all sections are empty.</li> <li>A background MOC is created that reads some JSON data from a resource file and add objects to the context.</li> <li>The background MOC is saved.</li> </ol> <p>(Btw. the cache file is </p> <pre><code> Library/Caches/&lt;bundle-id&gt;/.CoreDataCaches/SectionInfoCaches/&lt;tablename&gt;/sectionInfo </code></pre> <p>in the application bundle.)</p> <p>When the app is started the second time, the fetched results controller checks whether the section info cache is still valid or has to be recreated. According to the documentation it compares the modification times of the persistent store file and the section cache file.</p> <p>Now the interesting part: If (in the first run) the creation of the store file (step 1) and saving the updated context (step 4) <em>happen in the same second</em>, then the modification date of the store file <em>is not changed</em> in step 4!!</p> <p>Therefore the section cache file is still seen as valid and <em>not recreated</em>. Since all sections were empty (in step 2), the FRC uses this cached information and displays only empty sections.</p> <p>The background MOC is started again and saves the context. Now the store file has a new modification date, therefore the sections and rows are displayed correctly in the third run of the app.</p> <p>To confirm my "theory", I did a manual "touch" of the store file between first and second run to enforce a changed modification date. All sections and rows were then displayed correctly.</p> <p>(I tested this only in the iPhone Simulator. I don't know if the HFS+ file system generally has a 1 second resolution of the modification date, or if SQLite does something special here. I will try to investigate that later.)</p> <p><em>Conclusion:</em> If the creation of the store file and saving modified data happen in the same second, a section info cache file might not be regenerated if necessary.</p>
    singulars
    1. This table or related slice is empty.
    1. POUITableView with NSFetchedResultsController Does Not Load the Second Time
      singulars
      1. PTQuestion
    1. PTAnswer
    1. USMartin R
    1. USMartin R
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. POUITableView with NSFetchedResultsController Does Not Load the Second Time
      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. VTAcceptedByOriginator
    2. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTBountyClose
    3. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    1. COThis must be the case as I'm working with a small data set right now and the update happens very quickly. The other app I mentioned earlier uses a much larger data set where the store file creation and MOC save would probably never happen in the same second.
      singulars
      1. PO
      1. USscottoliver
    2. COremoving the cache in my case solved this problem.. But this is kinda wierd bug.
      singulars
      1. PO
      1. USJoão Nunes
 

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