Skip to content

feat(family): add Family and FamilyMember local tables - #530

Open
plusmobileapps wants to merge 1 commit into
claude/family-supabase-schemafrom
claude/family-local-schema
Open

feat(family): add Family and FamilyMember local tables#530
plusmobileapps wants to merge 1 commit into
claude/family-supabase-schemafrom
claude/family-local-schema

Conversation

@plusmobileapps

Copy link
Copy Markdown
Collaborator

Stack 2/3 — stacked on #529. Review that one first; this diff shows only the SQLDelight changes once #529 is merged.

What

The local cache for the families / family_members tables added in #529, plus their DI bindings. Nothing consumes the queries yet — the repository that does is in stack 3/3.

Why these aren't offline-first

Unlike GroceryList and RecipeBook, these carry no clientId / isDirty / getUnsynced columns. That's deliberate, and it's the main thing to push back on if you disagree.

Membership is inherently a server concept. Creating a family offline could collide with an invite accepted on another device, and the one-family-per-user rule can only be arbitrated by the database. So these are read caches refreshed from the server, and writes (in stack 3/3) go remote-first and throw — the same treatment RecipeBookCollaborationRepository gives collaboration state.

Members are cached locally (grocery's model) rather than fetched per-view (recipe books' model), so the Family screen can expose an observable Flow and render offline. That's the one place the two existing implementations diverge, and grocery's is the better shape.

Schema

Goes to version 12. verifyCommonMainDatabaseMigration passes, and 12.db is regenerated rather than hand-edited.

FamilyMember.isOwner exists because the owner's row is synthesized server-side by the family_members_with_profiles RPC and arrives with a null remoteIdrole alone can't distinguish them.

🤖 Generated with Claude Code

Local cache for the families/family_members tables added in the previous commit.
Nothing consumes the queries yet — the repository that does lands next.

Deliberately not offline-first: unlike GroceryList and RecipeBook these carry no
clientId / isDirty / getUnsynced columns. Membership is inherently a server
concept — creating a family offline could collide with an invite accepted on
another device, and the one-family-per-user rule can only be arbitrated by the
database. So these are read caches refreshed from the server, which is also how
RecipeBookCollaborationRepository treats collaboration state.

Members are cached locally (grocery's model) rather than fetched per-view
(recipe books' model) so the Family screen can expose an observable Flow and
render offline.

Schema goes to version 12; verifyCommonMainDatabaseMigration passes.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant