Package: ducklake 0.9.0.9000

The rule the lake enforces | Rules as views | Running the checks | Gating a load | Recording the outcome on the commit | Which rows failed | Rules have history | Rules and data as of a snapshot | Next to affirm and data-dict

Views | When a view is the right tool | Table and column comments | Variable labels

Introduction | Setting Up the Data Lake | Making Changes Over Time | Version 1: Initial data | Version 2: Update fuel efficiency data | Version 3: Add efficiency classification | Version 4: Correct an error | Exploring Version History | List all snapshots | Query a specific version | Query data as of a specific timestamp | Comparing Versions | Restoring Previous Versions | Pinning a Whole Session to a Snapshot | Row Lineage | Use Cases for Time Travel | Metadata and Audit Information

Introduction | Building Some History | Plotting the Timeline | How Much Changed | Browsing the Changes | How the Data Is Stored | Plotting the Whole Lake | Customizing the Plots | Learn More

What a lake looks like | Which catalog | Where the data goes | Who can reach it | Day-one setup | Upgrading | Where to next

What a DuckLake is | Install | Attach a lake | Add a table | Why most calls sit inside with_transaction() | Read a table | Change a table | See the history | Detach | Where to go next

Introduction | Setup: Loading Initial Data | Approach 1: with_transaction() (Recommended) | Why use with_transaction()? | Single Operation with Metadata | Multiple Operations in a Single Transaction | Automatic Rollback on Error | Approach 2: Manual Transaction Control | When to use manual transactions? | Basic Manual Transaction Workflow | Manual Rollback | Snapshot Metadata: At Commit Time vs After the Fact | Viewing Transaction History | Working with several writers | Comparison: with_transaction() vs Manual Control | Best Practices | Key Concepts Summary

How it works | Setup | Small writes are automatically inlined | Incremental updates stay inlined | Removing rows | Large writes bypass inlining automatically | Configuring the inlining threshold | Global default | Per-connection at attach time | Per-table persistent override | Disable inlining | Flushing inlined data to Parquet | Flushing a specific table | Checkpoint: one-stop maintenance | Time travel with inlined data | When to use inlining | What inlining does not change | Regulated environments | Summary

Choosing a Modification Approach | For incremental changes: the rows_* functions | For update-or-insert: rows_upsert() | For staging syncs and conditional merges: merge_into() | For schema changes: evolve in place | For structural or bulk changes: replace_table() | Group related changes with with_transaction() | Examples | Incremental changes with the rows_* functions | Updating specific rows with replace_table() | Adding derived columns | Reshaping the schema in place | Filtering rows with replace_table() | Time Travel: Accessing Previous Versions

Introduction | Installing the extension | Connecting to a shared lake | Connecting to a plain database | Serving a lake of your own | A note on access | Quack or a shared catalog? | Caveats | Learn more

Introduction | DuckLake's Two-Component Architecture | Storage Options | Storage Patterns | Cloud Storage Credentials | Inspecting DuckLake Files | Catalog Files | Storage (Data) Files | Understanding File Organization | Backup Strategies | Backing Up the Catalog | Copying the Catalog | Backing Up Storage (Data Files) | Local Storage Backup | Cloud Storage Backup | Recovery Procedures | Recovering from Catalog Backup | Recovering from Data File Loss | Routine Maintenance | Maintenance Considerations | Complete Backup Example | Cleanup | Summary

From a data frame | From a file | From a URL | From a dplyr pipeline | Derive a table inside the database | Put tables in schemas | Register Parquet files in place | Migrate a DuckDB database | Exchange data with Iceberg