Implement generic contextual repository pattern for posts (#991)

* Add documentation for wp_mobile_cache contextual mappings

Added comprehensive documentation for implementing database mappings
for WordPress REST API contextual types in wp_mobile_cache.

Changes:
- Created CLAUDE.md with quick reference for common tasks
- Created docs/IMPLEMENTING_MAPPINGS.md with detailed step-by-step guide
- Documents the process for generating concrete types via cargo expand
- Explains field analysis, mapping implementation, and migration creation
- Provides helper function reference and common patterns

* Implement view and embed context mappings for posts

Reorganized post mappings to support multiple WordPress API contexts
with separate implementations for edit, view, and embed.

Changes:
- Moved posts.rs to posts/ directory with separate files per context
- Created posts/edit.rs (existing edit context mapping)
- Created posts/view.rs (25 fields, no raw content or edit-only fields)
- Created posts/embed.rs (9 fields, minimal data for embedding)
- Created posts/mod.rs with shared helper for term relationship extraction
- All contexts use extract_categories_and_tags() helper to avoid duplication
- All 50 existing tests pass without modification

* Refactor post repository to support multiple WordPress REST API contexts

Consolidate mapping layer into repository and add generic context support
for edit, view, and embed contexts. This eliminates unnecessary abstraction
layers and provides a cleaner architecture.

Architecture changes:
- Create new context module with IsContext and PostContext traits
- Add context marker types: EditContext, ViewContext, EmbedContext
- Create db_types module for database type definitions separate from logic
- Split db_types/posts into separate files per context (edit, view, embed)
- Remove mappings/posts directory entirely

Repository improvements:
- Make PostRepository generic over PostContext trait: PostRepository<C>
- Implement generic read operations via impl<C: PostContext>
- Keep context-specific write operations in impl PostRepository<EditContext>
- Move FromRowWithTerms trait into repository as private implementation detail
- Implement FromRowWithTerms for all three contexts (Edit, View, Embed)
- Add extract_categories_and_tags helper function

Benefits:
- Clean separation: db_types for structs, repository for logic
- Reduced code scatter - related functionality in one place
- Generic read operations work across all contexts
- Type-safe context handling via trait bounds
- Easier to navigate with split files per context

Changes:
- Add src/context.rs with context traits and marker types
- Add src/db_types/ module with posts submodule split by context
- Remove src/mappings/posts/ directory
- Refactor src/repository/posts.rs to be generic over context
- Update test fixtures to use PostRepository<EditContext>
- Add Default impl and private_bounds allow attribute

* Return Ok(None) instead of error for not-found queries in wp_mobile_cache

Changed repository select methods to return `Result<Option<T>>` instead of
`Result<T>`, treating "not found" as a valid outcome rather than an error
condition. This is more idiomatic Rust and provides better clarity for callers.

Uses rusqlite's built-in `OptionalExtension::optional()` method to cleanly
convert `rusqlite::Result<T>` into `Result<Option<T>, SqliteDbError>`,
automatically handling `QueryReturnedNoRows` as `Ok(None)` while preserving
other errors.

Changes:
- Import `rusqlite::OptionalExtension` in repository/posts.rs
- Update `select_by_rowid` to return `Result<Option<DbPost>>`
- Update `select_by_post_id` to return `Result<Option<DbPost>>`
- Refactor query error handling using `let-else` pattern for clarity
- Update `delete_by_post_id` to handle new Option return type
- Update all test assertions to work with Option values
- Rename tests to reflect new behavior (returns_none vs returns_error)

* Update IMPLEMENTING_MAPPINGS.md to reflect current architecture

The documentation was outdated and referenced the old structure where mapping
logic lived in `src/mappings/{entity}/`. Updated to reflect the current
architecture where database operations are properly separated.

Current architecture:
- `src/db_types/`: Type-only definitions (column enums, wrapper structs)
- `src/repository/`: All database interaction logic (FromRowWithTerms + upsert)
- `src/mappings/helpers.rs`: Reusable conversion utilities

This maintains proper separation of concerns where the repository pattern
handles all database operations in one place, avoiding split responsibilities.

Changes:
- Update Step 4 to reference `db_types/` instead of `mappings/`
- Add new Step 5 explaining FromRowWithTerms goes in repository
- Update all file path references throughout document
- Update checklist to reflect correct module locations
- Update file organization diagram with accurate structure
- Add architecture summary explaining the separation

* Rename IMPLEMENTING_MAPPINGS.md to ADDING_NEW_ENTITIES.md

The old name no longer accurately describes the document's purpose. The guide
covers the complete process of adding database support for new WordPress
entity types, not just "implementing mappings."

Changes:
- Rename docs/IMPLEMENTING_MAPPINGS.md to docs/ADDING_NEW_ENTITIES.md
- Update self-reference in file organization diagram
- Update references in CLAUDE.md with more descriptive text

* Remove private FromRowWithTerms trait in favor of PostContext method

Eliminated the private `FromRowWithTerms` trait by adding the `from_row_with_terms`
method directly to the `PostContext` trait. This removes the need for
`#[allow(private_bounds)]` and simplifies the architecture.

Benefits:
- No more private trait with unclear purpose
- No compiler warning suppression needed
- PostContext implementations are now complete in the repository module
- Clearer architecture: context trait defines both types and behavior

Changes:
- Add `from_row_with_terms` method to `PostContext` trait in context.rs
- Move `PostContext` implementations from context.rs to repository/posts.rs
- Replace `impl FromRowWithTerms for DbPost` with `impl PostContext for Context`
- Remove `where C::DbPost: FromRowWithTerms` bounds from repository methods
- Update call sites from `C::DbPost::from_row_with_terms` to `C::from_row_with_terms`
- Update return types from `Result<Self, ...>` to `Result<Self::DbPost, ...>`

* Use lazy closure for term relationship loading to avoid unnecessary queries

Changed `from_row_with_terms` to accept a closure instead of pre-fetched term
relationships. This allows contexts to decide whether they need terms, avoiding
unnecessary database queries for contexts like Embed that don't use them.

Benefits:
- EmbedContext no longer queries term_relationships table unnecessarily
- Caller provides HOW to fetch, implementation decides IF to fetch
- Proper separation of concerns and dependency injection
- Maintains efficient batch loading for select_all (pre-fetch once, lazy access)

Implementation:
- Each context calls `fetch_terms()?` only if it needs categories/tags
- EditContext and ViewContext: Call closure to get terms
- EmbedContext: Never calls closure, avoiding the query entirely

Changes:
- Update PostContext trait method to accept FnOnce closure
- Update repository methods to pass closures instead of pre-fetching
- EditContext/ViewContext: Call fetch_terms() and use results
- EmbedContext: Don't call fetch_terms(), add explanatory comment

* Add database migrations for posts_view_context and posts_embed_context tables

Created missing migrations for ViewContext and EmbedContext post tables to
complete the contextual repository implementation.

ViewContext table:
- Includes most fields from EditContext
- Excludes edit-only fields (password, permalink_template, generated_slug)
- Excludes raw fields (guid_raw, title_raw, content_raw, content_block_version)
- 29 columns total

EmbedContext table:
- Minimal fields for embedding posts in other content
- Only includes: id, date, link, slug, post_type, title_rendered, author,
  excerpt fields, featured_media
- 14 columns total

Changes:
- Add 0004-create-posts-view-context-table.sql migration
- Add 0005-create-posts-embed-context-table.sql migration
- Update MIGRATION_QUERIES array from 3 to 5 migrations
- Includes proper indexes and foreign key constraints
- Uses STRICT mode for type safety

* Add integration tests with helper to verify column enum schema matching

Added PRAGMA-based tests to catch mismatches between column enum definitions
and actual database table schemas, with a reusable helper function to reduce
test duplication.

Implementation:
- Add `get_table_column_names()` helper in test_fixtures.rs
- Use helper to query actual column order from SQLite PRAGMA table_info
- Verify each enum value maps to correct column name using `.as_index()`
- Test the same code path production uses (ColumnIndex trait)
- Verify total column count matches last enum value

Benefits:
- Catches column ordering bugs immediately in CI/CD
- Reduces test duplication with shared helper function
- Self-documenting: compares enum values against expected names
- No runtime overhead: tests run during development only
- Tests fail immediately if enums get out of sync with SQL

All three context tests (Edit, View, Embed) now pass with real migrations.

* Add upsert methods for ViewContext and EmbedContext with RETURNING optimization

Implement write operations for view and embed contexts to complete the contextual repository pattern. Use SQLite's RETURNING clause to eliminate separate SELECT queries for rowid retrieval.

Changes:
- Add `upsert()` and `upsert_batch()` methods for ViewContext and EmbedContext
- Refactor all three contexts (Edit/View/Embed) to use `RETURNING rowid` instead of separate SELECT statements
- ViewContext syncs term relationships (categories and tags)
- EmbedContext has no term relationships (minimal fields only)
- Add test to verify bundled SQLite version supports RETURNING (3.50.2 >= 3.35.0)

Performance improvements:
- Eliminates 3 database round trips per upsert (one per context)
- Safe for iOS and Android: rusqlite bundles SQLite 3.50.2 which includes RETURNING support

* Remove unnecessary type re-exports from posts repository

The re-exports created an alternative import path without adding semantic value. Types are already well-organized in db_types::posts module where consumers can import them directly. Keeping imports in a single canonical location improves code searchability.

* Move PostContext trait to repository and update documentation

Move entity-specific trait definitions to their repository modules for better organization. The context.rs module now contains only the generic IsContext trait and context marker types.

Changes:
- Move PostContext trait from context.rs to repository/posts.rs
- Update context.rs to focus on generic infrastructure only
- Rewrite ADDING_NEW_ENTITIES.md to be concise and accurate
- Remove outdated references to CONTEXT_FIELD_ANALYSIS.md
- Update trait method documentation to not assume all entities use term relationships
- Add reminder to update platform test migration count assertions
- Update Swift and Kotlin tests to expect 5 migrations (was 3)

Documentation improvements:
- Reduced from 487 lines to 86 lines
- Focus on general process rather than exhaustive examples
- Points to posts.rs as reference implementation
- Clarifies that entity needs determine trait method signatures

* Remove redundant wp_mobile_cache/CLAUDE.md

The file contained outdated information referencing the old mappings/ structure and non-existent documentation files. The docs/ADDING_NEW_ENTITIES.md already serves as the canonical guide for implementing new entities.

* Improve documentation example in get_table_column_names

Update the example to demonstrate the correct usage pattern with column
enum indices instead of hardcoded numeric indices.

Changes:
- Use `Rowid.as_index()` instead of `0`
- Use `SiteId.as_index()` instead of `1`
- Add import for `PostEditContextColumn`

* Standardize error handling in wp_mobile_cache tests

Replace unwrap().expect() pattern with expect().expect() for better error messages.
The first expect() now handles Result errors with descriptive messages, while the
second expect() handles Option types with context-specific messages.

Changes:
- Update posts.rs tests to use expect() with "Failed to select/read post..." messages
- Update posts_constraint_tests.rs with descriptive Result error messages
- Update posts_multi_site_tests.rs for consistency
- Update posts_transaction_tests.rs for consistency

* Extract SQLite version checking utilities for client use

Add reusable functions for querying SQLite version and checking RETURNING support.
Clients can now verify SQLite compatibility at runtime without duplicating logic.

Changes:
- Add `get_sqlite_version()` to query SQLite version via `QueryExecutor`
- Add `does_sqlite_support_returning()` to check if version >= 3.35.0
- Refactor `test_bundled_sqlite_version_supports_returning` to use new utilities
- Add unit test for version parsing with supported, unsupported, and invalid versions

* Document minimum iOS 15 requirement for SQLite RETURNING support

Add platform requirements note explaining that iOS 15 (SQLite 3.36.0) is the
minimum supported version to ensure RETURNING clause compatibility.

Changes:
- Add platform requirements section in ADDING_NEW_ENTITIES.md
- Link to YapDatabase wiki for SQLite version reference by OS

Author: oguzkocer

native/kotlin/api/kotlin/src/integrationTest/kotlin/WordPressApiCacheTest.kt

@@ -11,7 +11,7 @@ class WordPressApiCacheTest {
 
     @Test
     fun testThatMigrationsWork() = runTest {
-        assertEquals(3, WordPressApiCache().performMigrations())
+        assertEquals(5, WordPressApiCache().performMigrations())
     }
 
     @Test

native/swift/Tests/wordpress-api-cache/WordPressApiCacheTests.swift

@@ -13,7 +13,7 @@ actor Test {
 
     @Test func testMigrationsWork() async throws {
         let migrationsPerformed = try await self.cache.performMigrations()
-        #expect(migrationsPerformed == 3)
+        #expect(migrationsPerformed == 5)
     }
 
     #if !os(Linux)

wp_mobile_cache/docs/ADDING_NEW_ENTITIES.md

@@ -0,0 +1,81 @@
+# Adding Database Support for New WordPress Entities
+
+This guide explains how to add caching support for WordPress REST API entity types (posts, comments, users, etc.).
+
+## Overview
+
+WordPress REST API returns different fields based on the `context` parameter (`edit`, `view`, `embed`). Each context requires its own database table since field sets differ significantly.
+
+**Architecture:**
+- `context.rs` - Generic `IsContext` trait and context marker types (EditContext, ViewContext, EmbedContext)
+- `db_types/{entity}/` - Column enums and wrapper structs (types only, no logic)
+- `repository/{entity}.rs` - Entity-specific trait definitions and all database operations
+
+Use the existing `posts` implementation in `src/repository/posts.rs` as the primary reference.
+
+## Discovering Context Fields
+
+The `wp_api` crate uses procedural macros to generate context-specific types. To see what fields are actually available:
+
+```bash
+# Generate expanded code for an entity
+cargo expand -p wp_api posts > /tmp/generated_posts.rs
+# or
+cargo expand -p wp_api comments > /tmp/generated_comments.rs
+```
+
+Open the generated file and search for the context-specific types (e.g., `AnyPostWithEditContext`, `AnyPostWithViewContext`, `AnyPostWithEmbedContext`). Compare fields across contexts to understand what differs.
+
+**Important**: Don't assume patterns - field availability varies by endpoint. Always verify against the expanded types.
+
+## Implementation Steps
+
+When adding a new entity type (e.g., implementing cache support for comments):
+
+1. **Create type definitions** in `src/db_types/comments/`:
+   - `mod.rs` - Re-exports
+   - `edit.rs`, `view.rs`, `embed.rs` - One file per context
+   - Each file contains: column enum (matching SQL table order) + database wrapper struct
+
+2. **Define entity-specific trait and implement database logic** in `src/repository/comments.rs`:
+   - Define `CommentContext` trait extending `IsContext` with associated types and row mapping method
+   - The method signature depends on your entity's needs (e.g., posts use lazy closures for term loading)
+   - Implement trait for each context (EditContext, ViewContext, EmbedContext)
+   - Create generic `CommentRepository<C: CommentContext>`
+   - Implement upsert methods for contexts that need write operations
+
+3. **Create migrations** for each context table:
+   - `migrations/NNNN-create-comments-edit-context-table.sql`
+   - `migrations/NNNN-create-comments-view-context-table.sql`
+   - `migrations/NNNN-create-comments-embed-context-table.sql`
+   - Add to `MIGRATION_QUERIES` array in `lib.rs`
+   - Update migration count assertions in platform test files:
+     - `native/swift/Tests/wordpress-api-cache/WordPressApiCacheTests.swift`
+     - `native/kotlin/api/kotlin/src/integrationTest/kotlin/WordPressApiCacheTest.kt`
+
+4. **Add module exports** in `src/db_types/mod.rs`:
+   ```rust
+   pub mod comments;
+   ```
+
+5. **Write tests** in the repository file covering round-trip persistence and enum variants
+
+## Key Design Decisions
+
+**Column enum ordering**: Column indexes in the enum must match the exact order in SQL `CREATE TABLE` statements and all `SELECT *` queries. Add PRAGMA-based integration tests to verify this (see `test_post_edit_context_column_enum_matches_schema` in `repository/posts.rs` for reference).
+
+**Lazy data loading**: If your entity requires optional related data (e.g., posts use term relationships for categories/tags), use `FnOnce()` closures in the trait method. This allows contexts that don't need the data to avoid unnecessary database queries by simply not calling the closure. See `PostContext::from_row_with_terms` for an example.
+
+**Repository pattern**: All database operations belong in `repository/` - this includes both SQL execution AND row-to-type mapping logic. The `db_types/` module contains only type definitions.
+
+**RETURNING optimization**: Use SQLite's `RETURNING rowid` clause in upsert statements to eliminate separate SELECT queries. Our bundled SQLite version (3.50.2) fully supports this.
+
+**Platform requirements**: The minimum supported iOS version for this library is iOS 15, which bundles SQLite 3.36.0. This ensures RETURNING clause support (added in SQLite 3.35.0) across all target platforms. See [SQLite versions bundled with OS](https://github.com/yapstudios/YapDatabase/wiki/SQLite-version-(bundled-with-OS)) for reference.
+
+## Reference Implementation
+
+See `src/repository/posts.rs` for a complete working example including:
+- Context trait implementations with lazy closure pattern
+- Generic repository with context-specific methods
+- PRAGMA tests for column schema verification
+- Comprehensive test coverage

wp_mobile_cache/migrations/0004-create-posts-view-context-table.sql

@@ -0,0 +1,57 @@
+CREATE TABLE `posts_view_context` (
+  -- Internal DB field (auto-incrementing)
+  `rowid` INTEGER PRIMARY KEY AUTOINCREMENT,
+
+  -- Site identifier (foreign key to sites table)
+  `db_site_id` INTEGER NOT NULL REFERENCES sites(id) ON DELETE CASCADE,
+
+  -- Top-level non-nullable fields
+  `id` INTEGER NOT NULL,
+  `date` TEXT NOT NULL,
+  `date_gmt` TEXT NOT NULL,
+  `link` TEXT NOT NULL,
+  `modified` TEXT NOT NULL,
+  `modified_gmt` TEXT NOT NULL,
+  `slug` TEXT NOT NULL,
+  `status` TEXT NOT NULL,
+  `post_type` TEXT NOT NULL,
+  `template` TEXT NOT NULL,
+
+  -- Top-level optional fields
+  `author` INTEGER,
+  `featured_media` INTEGER,
+  `sticky` INTEGER,
+  `parent` INTEGER,
+  `menu_order` INTEGER,
+
+  -- Optional enums (stored as TEXT)
+  `comment_status` TEXT,
+  `ping_status` TEXT,
+  `format` TEXT,
+
+  -- Complex optional fields (JSON)
+  `meta` TEXT,
+
+  -- Nested: guid (only rendered field in view context)
+  `guid_rendered` TEXT NOT NULL,
+
+  -- Nested: title (only rendered field in view context)
+  `title_rendered` TEXT NOT NULL,
+
+  -- Nested: content (only rendered and protected fields in view context)
+  `content_rendered` TEXT NOT NULL,
+  `content_protected` INTEGER,
+
+  -- Nested: excerpt (entire struct is optional)
+  `excerpt_raw` TEXT,
+  `excerpt_rendered` TEXT,
+  `excerpt_protected` INTEGER,
+
+  -- Client-side cache metadata: when this post was last fetched from the WordPress API
+  `last_fetched_at` TEXT NOT NULL DEFAULT (strftime('%Y-%m-%dT%H:%M:%fZ', 'now')),
+
+  FOREIGN KEY (db_site_id) REFERENCES sites(id) ON DELETE CASCADE
+) STRICT;
+
+CREATE UNIQUE INDEX idx_posts_view_context_unique_db_site_id_and_id ON posts_view_context(db_site_id, id);
+CREATE INDEX idx_posts_view_context_db_site_id ON posts_view_context(db_site_id);

wp_mobile_cache/migrations/0005-create-posts-embed-context-table.sql

@@ -0,0 +1,36 @@
+CREATE TABLE `posts_embed_context` (
+  -- Internal DB field (auto-incrementing)
+  `rowid` INTEGER PRIMARY KEY AUTOINCREMENT,
+
+  -- Site identifier (foreign key to sites table)
+  `db_site_id` INTEGER NOT NULL REFERENCES sites(id) ON DELETE CASCADE,
+
+  -- Top-level non-nullable fields (minimal set for embed context)
+  `id` INTEGER NOT NULL,
+  `date` TEXT NOT NULL,
+  `link` TEXT NOT NULL,
+  `slug` TEXT NOT NULL,
+  `post_type` TEXT NOT NULL,
+
+  -- Nested: title (only rendered field in embed context)
+  `title_rendered` TEXT NOT NULL,
+
+  -- Top-level optional fields
+  `author` INTEGER,
+
+  -- Nested: excerpt (entire struct is optional)
+  `excerpt_raw` TEXT,
+  `excerpt_rendered` TEXT,
+  `excerpt_protected` INTEGER,
+
+  -- Featured media
+  `featured_media` INTEGER,
+
+  -- Client-side cache metadata: when this post was last fetched from the WordPress API
+  `last_fetched_at` TEXT NOT NULL DEFAULT (strftime('%Y-%m-%dT%H:%M:%fZ', 'now')),
+
+  FOREIGN KEY (db_site_id) REFERENCES sites(id) ON DELETE CASCADE
+) STRICT;
+
+CREATE UNIQUE INDEX idx_posts_embed_context_unique_db_site_id_and_id ON posts_embed_context(db_site_id, id);
+CREATE INDEX idx_posts_embed_context_db_site_id ON posts_embed_context(db_site_id);

wp_mobile_cache/src/context.rs

@@ -0,0 +1,101 @@
+/// Base trait for WordPress REST API context types.
+///
+/// This trait is entity-agnostic and only handles table naming and context identification.
+/// Entity-specific traits (e.g., PostContext) are defined in their respective repository modules.
+pub trait IsContext: 'static + Copy {
+    /// The context suffix used in table names.
+    ///
+    /// # Example
+    /// ```
+    /// // EditContext::context_suffix() => "edit"
+    /// // ViewContext::context_suffix() => "view"
+    /// // EmbedContext::context_suffix() => "embed"
+    /// ```
+    fn context_suffix() -> &'static str;
+
+    /// The WpContext enum variant for this context.
+    fn wp_context() -> wp_api::WpContext;
+
+    /// Generate the full table name for a given entity type prefix.
+    ///
+    /// # Example
+    /// ```
+    /// // EditContext::table_name("posts") => "posts_edit_context"
+    /// // EditContext::table_name("comments") => "comments_edit_context"
+    /// ```
+    fn table_name(prefix: &str) -> String {
+        format!("{}_{}_context", prefix, Self::context_suffix())
+    }
+}
+
+/// Marker type for Edit context
+#[derive(Debug, Clone, Copy)]
+pub struct EditContext;
+
+/// Marker type for View context
+#[derive(Debug, Clone, Copy)]
+pub struct ViewContext;
+
+/// Marker type for Embed context
+#[derive(Debug, Clone, Copy)]
+pub struct EmbedContext;
+
+// Implement base IsContext trait for each marker type
+impl IsContext for EditContext {
+    fn context_suffix() -> &'static str {
+        "edit"
+    }
+
+    fn wp_context() -> wp_api::WpContext {
+        wp_api::WpContext::Edit
+    }
+}
+
+impl IsContext for ViewContext {
+    fn context_suffix() -> &'static str {
+        "view"
+    }
+
+    fn wp_context() -> wp_api::WpContext {
+        wp_api::WpContext::View
+    }
+}
+
+impl IsContext for EmbedContext {
+    fn context_suffix() -> &'static str {
+        "embed"
+    }
+
+    fn wp_context() -> wp_api::WpContext {
+        wp_api::WpContext::Embed
+    }
+}
+
+#[cfg(test)]
+mod tests {
+    use super::*;
+
+    #[test]
+    fn test_table_name_generation() {
+        assert_eq!(EditContext::table_name("posts"), "posts_edit_context");
+        assert_eq!(ViewContext::table_name("posts"), "posts_view_context");
+        assert_eq!(EmbedContext::table_name("posts"), "posts_embed_context");
+
+        assert_eq!(EditContext::table_name("comments"), "comments_edit_context");
+        assert_eq!(ViewContext::table_name("comments"), "comments_view_context");
+    }
+
+    #[test]
+    fn test_context_suffix() {
+        assert_eq!(EditContext::context_suffix(), "edit");
+        assert_eq!(ViewContext::context_suffix(), "view");
+        assert_eq!(EmbedContext::context_suffix(), "embed");
+    }
+
+    #[test]
+    fn test_wp_context() {
+        assert_eq!(EditContext::wp_context(), wp_api::WpContext::Edit);
+        assert_eq!(ViewContext::wp_context(), wp_api::WpContext::View);
+        assert_eq!(EmbedContext::wp_context(), wp_api::WpContext::Embed);
+    }
+}

wp_mobile_cache/src/db_types.rs

@@ -0,0 +1 @@
+pub mod posts;

wp_mobile_cache/src/db_types/posts/edit.rs

@@ -0,0 +1,58 @@
+use crate::{DbSite, RowId, mappings::ColumnIndex};
+use wp_api::posts::AnyPostWithEditContext;
+
+/// Column indexes for posts_edit_context table.
+/// These must match the order of columns in the CREATE TABLE statement.
+#[repr(usize)]
+#[derive(Debug, Clone, Copy)]
+pub(crate) enum PostEditContextColumn {
+    Rowid = 0,
+    SiteId = 1,
+    Id = 2,
+    Date = 3,
+    DateGmt = 4,
+    Link = 5,
+    Modified = 6,
+    ModifiedGmt = 7,
+    Slug = 8,
+    Status = 9,
+    PostType = 10,
+    Password = 11,
+    Template = 12,
+    PermalinkTemplate = 13,
+    GeneratedSlug = 14,
+    Author = 15,
+    FeaturedMedia = 16,
+    Sticky = 17,
+    Parent = 18,
+    MenuOrder = 19,
+    CommentStatus = 20,
+    PingStatus = 21,
+    Format = 22,
+    Meta = 23,
+    GuidRaw = 24,
+    GuidRendered = 25,
+    TitleRaw = 26,
+    TitleRendered = 27,
+    ContentRaw = 28,
+    ContentRendered = 29,
+    ContentProtected = 30,
+    ContentBlockVersion = 31,
+    ExcerptRaw = 32,
+    ExcerptRendered = 33,
+    ExcerptProtected = 34,
+    LastFetchedAt = 35,
+}
+
+impl ColumnIndex for PostEditContextColumn {
+    fn as_index(&self) -> usize {
+        *self as usize
+    }
+}
+
+pub struct DbAnyPostWithEditContext {
+    pub row_id: RowId,
+    pub site: DbSite,
+    pub post: AnyPostWithEditContext,
+    pub last_fetched_at: String,
+}

wp_mobile_cache/src/db_types/posts/embed.rs

@@ -0,0 +1,36 @@
+use crate::{DbSite, RowId, mappings::ColumnIndex};
+use wp_api::posts::AnyPostWithEmbedContext;
+
+/// Column indexes for posts_embed_context table.
+/// These must match the order of columns in the CREATE TABLE statement.
+#[repr(usize)]
+#[derive(Debug, Clone, Copy)]
+pub(crate) enum PostEmbedContextColumn {
+    Rowid = 0,
+    SiteId = 1,
+    Id = 2,
+    Date = 3,
+    Link = 4,
+    Slug = 5,
+    PostType = 6,
+    TitleRendered = 7,
+    Author = 8,
+    ExcerptRaw = 9,
+    ExcerptRendered = 10,
+    ExcerptProtected = 11,
+    FeaturedMedia = 12,
+    LastFetchedAt = 13,
+}
+
+impl ColumnIndex for PostEmbedContextColumn {
+    fn as_index(&self) -> usize {
+        *self as usize
+    }
+}
+
+pub struct DbAnyPostWithEmbedContext {
+    pub row_id: RowId,
+    pub site: DbSite,
+    pub post: AnyPostWithEmbedContext,
+    pub last_fetched_at: String,
+}