Documentation Source Text

Check-in [47c1a4a97e]
Login

Many hyperlinks are disabled.
Use anonymous login to enable hyperlinks.

Overview
Comment:Further updates to fileformat.html.
Downloads: Tarball | ZIP archive
Timelines: family | ancestors | descendants | both | trunk
Files: files | file ages | folders
SHA1: 47c1a4a97e8cded2b307f162f600bbf2edaedfc0
User & Date: dan 2009-04-27 18:20:50.000
Context
2009-04-28
15:51
fileformat.html updates. (check-in: 7962286919 user: dan tags: trunk)
2009-04-27
18:20
Further updates to fileformat.html. (check-in: 47c1a4a97e user: dan tags: trunk)
11:59
Updates to fileformat.html. (check-in: 712d82fbd7 user: dan tags: trunk)
Changes
Unified Diff Ignore Whitespace Patch
Changes to pages/fileformat.in.
2470
2471
2472
2473
2474
2475
2476























































































2477
2478
2479
2480
2481
2482
2483
    any method may be used by an SQLite database writer to update the database
    file-system representation. SQLite itself uses the "rollback-journal method"
    described in section <cite>rollback_journal_method</cite>. For this reason,
    section <cite>rollback_journal_method</cite> contains numbered requirements
    but section <cite>rollforward_journal_method</cite> does not.

  [h3 "The Rollback-Journal Method" rollback_journal_method]























































































  <p>
    SQLite is required 
    to do make all modifications associated with the transaction such that 
    the database image is modified atomically. If an application, OS or 
    power failure occurs while SQLite is updating the database, upon recovery 
    the contents of the database must reflect either that all modifications 
    associated with the database transaction were successfully applied, or 







>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>







2470
2471
2472
2473
2474
2475
2476
2477
2478
2479
2480
2481
2482
2483
2484
2485
2486
2487
2488
2489
2490
2491
2492
2493
2494
2495
2496
2497
2498
2499
2500
2501
2502
2503
2504
2505
2506
2507
2508
2509
2510
2511
2512
2513
2514
2515
2516
2517
2518
2519
2520
2521
2522
2523
2524
2525
2526
2527
2528
2529
2530
2531
2532
2533
2534
2535
2536
2537
2538
2539
2540
2541
2542
2543
2544
2545
2546
2547
2548
2549
2550
2551
2552
2553
2554
2555
2556
2557
2558
2559
2560
2561
2562
2563
2564
2565
2566
2567
2568
2569
2570
    any method may be used by an SQLite database writer to update the database
    file-system representation. SQLite itself uses the "rollback-journal method"
    described in section <cite>rollback_journal_method</cite>. For this reason,
    section <cite>rollback_journal_method</cite> contains numbered requirements
    but section <cite>rollforward_journal_method</cite> does not.

  [h3 "The Rollback-Journal Method" rollback_journal_method]

    <p>
      This section describes the method used by SQLite to update a database 
      image within a database file-system representation. This is one way
      to modify a database image in accordance with the requirements in the
      parent section. When overwriting database image A with database image B 
      using this method, assuming that to begin with database image A is 
      entirely contained within the database file and that the page-size of
      database image B is the same as that of database image A, the following 
      steps are taken:

    <ol>
      <li> <p>The start of the journal file is populated with data that is not
           a valid journal header.
      <li> <p>For each page in database image A that is not a free-list leaf 
           page and either does not exist in database image B or exists but
           is populated with different content, a record is written to the
           journal file. The record contains a copy of the original database
           image A page.
      <li> <p>The journal file is populated with a valid journal header. The
           page-count field of the journal header is set to the number of
           pages in database image A. The record-count is set to the number
           of records written to the journal file in step 2.
      <li> <p>The content of each page of database image B that is either not
           present or populated differently in database image A is copied
           into the database file. If database image B is smaller than database
           image A, the database file is truncated to the size required by
           database image B.
      <li> <p>One of several file-system operations that cause the journal file
           to become invalid is performed. For example:
           <ul>
             <li>The journal file is deleted from the file-system, or
             <li>The journal file is truncated to zero bytes in size, or
             <li>Some or all of the first 8 bytes of the journal file are
                 overwritten so that the journal file no longer begins with 
                 a well-formed journal header (and is therefore not valid).
           </ul>
    </ol>

    <p>
      During steps 1 and 2 of the above procedure, the database file-system 
      representation clearly contains database image A. The database file
      itself has not been modified, and the journal file is not valid (since
      it does not begin with a valid journal file header). Following step 3,
      the database file-system representation still contains database image
      A. The number of pages in the database image and the content of some
      pages now resides in the journal file, but the database image remains
      unchanged. During and following step 4, the current database image is
      still database image A. Although some or all of the pages in the 
      database file may have been overwritten or truncated away, a valid 
      journal records containing the original database image A data exists
      for all such pages that were not free-list leaf pages in database 
      image A. And although the size of the database file may have been
      modified, the size of the current database image, database image A, 
      is stored in the journal header.

    <p>
      Once step 5 of the above procedure is performed, the database file-system
      representation contains database image B. The journal file is no longer
      valid, so the database image consists of the contents of the database
      file, database image B.
  <p>
    Figure <cite>figure_filesystem2</cite> depicts a possible interim state 
    of the database file-system representation used while committing a transaction
    that replaces a four page database image with a three page database image.
    The contents of the initial database image pages are A, B, C and D respectively. 
    The final database image content is A, E and C. The intermim state depicted
    is that reached at the end of step 4 in the above procedure. In this state, 
    the file-system contains the initial database image, ABCD. However, if the 
    journal file were to be somehow invalidated, then the file-system would 
    contain the final database image, AEC.

    [Figure filesystem2.gif figure_filesystem2 "Interim file-system state used to atomically overwrite database image ABCD with AEC"]

    <p class=todo>
      The above does not explain multiple header journals. Or multi-file 
      transactions.

    <p class=todo> FINISH THIS!

  [h4 "Multiple Database Transactions" multi_db_transactions]

<!--




  <p>
    SQLite is required 
    to do make all modifications associated with the transaction such that 
    the database image is modified atomically. If an application, OS or 
    power failure occurs while SQLite is updating the database, upon recovery 
    the contents of the database must reflect either that all modifications 
    associated with the database transaction were successfully applied, or 
2577
2578
2579
2580
2581
2582
2583
2584
2585
2586
2587
2588
2589
2590
2591
2592
2593
2594
2595
2596
2597
2598
2599
2600
2601
2602
2603
2604






2605
2606
2607
2608
2609
2610
2611

2612
2613
2614
2615
2616
2617
2618
    <li> Deleting the journal file from the file-system, or
    <li> Truncating the journal file to zero bytes in size, or
    <li> Overwriting some or all of the first 8 bytes in the journal file
         so that the journal file no longer contains a well-formed journal
         header.
  </ul>

  <p>
    Figure <cite>figure_filesystem2</cite> depicts an interim file-system
    state that may be used when committing a transaction that replaces
    an initial database image that consists of 4 pages of page-size bytes each
    with a database image that consists of 3 pages, also of page-size bytes
    each. The contents of the initial database image pages are A, B, C and
    D respectively. The final database image content is A, E and C. As 
    depicted, the file-system contains the initial database image, ABCD.
    However, if the journal file were to be somehow invalidated, then the 
    file-system would contain the final database image, AEC.

    [Figure filesystem2.gif figure_filesystem2 "Interim file-system state used to atomically overwrite database image ABCD with AEC"]

  <p class=todo>
    The exception for free-list leaves.


  [h4 "Multiple Database Transactions" multi_db_transactions]

  <p class=todo>
    Deleting the master-journal is used as the atomic operation.







  [h3 "The Rollforward-Journal Method" rollforward_journal_method]

    <p class=todo>
      Describe the how the journal file can also be used as a roll 
      forward journal or "transaction log". This section does not 
      contain requirements.



[h1 "SQLite Interoperabilty Requirements" interoperability_requirements]

  [h2 "SQLite Locking Protocol" locking_protocol]

    <p>







<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<





>
>
>
>
>
>






|
>







2664
2665
2666
2667
2668
2669
2670
















2671
2672
2673
2674
2675
2676
2677
2678
2679
2680
2681
2682
2683
2684
2685
2686
2687
2688
2689
2690
2691
2692
2693
2694
2695
2696
    <li> Deleting the journal file from the file-system, or
    <li> Truncating the journal file to zero bytes in size, or
    <li> Overwriting some or all of the first 8 bytes in the journal file
         so that the journal file no longer contains a well-formed journal
         header.
  </ul>


















  [h4 "Multiple Database Transactions" multi_db_transactions]

  <p class=todo>
    Deleting the master-journal is used as the atomic operation.
-->

  [h3 "The Atomic-Write Method" atomic_write_method]

    <p class=todo>
      Describe the special atomic-write option.

  [h3 "The Rollforward-Journal Method" rollforward_journal_method]

    <p class=todo>
      Describe the how the journal file can also be used as a roll 
      forward journal or "transaction log". This section does not 
      contain requirements. It is only here to make the point that
      alternatives to the rollback journal method exist.


[h1 "SQLite Interoperabilty Requirements" interoperability_requirements]

  [h2 "SQLite Locking Protocol" locking_protocol]

    <p>