feat(PowerSync): add attachments support

[Chriztiaan]

Derived from Steven's efforts in powersync-ja/powersync-js#983, and addresses TanStack#1563.

Problem

PowerSync ships an attachment helper for syncing files (photos, documents) between local and remote storage. It's separate from regular synced tables: a local-only attachments table tracks each file's lifecycle (QUEUED_UPLOAD, SYNCED, QUEUED_DELETE), and an AttachmentQueue drives uploads/downloads in the background.

TanStackDB, on the other hand, gives you an optimistic, reactive, joinable view over synced data. For users who want to use the attachment helper alongside the PowerSync+TanstackDB integration there are blockers. Saving a file (in the local-only attachments table) and associating it with a record (e.g. setting user.photo_id) are two independent writes which could make data races and fatal errors a problem for data consistency.

The original POC (powersync-js#983) proved this integration was viable. This PR productionises a a subset of it as reusable functionality.

Solution

A TanStackDBAttachmentQueue that extends the SDK's AttachmentQueue (for saving and deleting a file) and backs it with a TanStack DB collection.

The package owns the collection-backed saveFile/delete implementation and leaves the wiring to the application (covered in documentation).

Future Work

After this has been released, we can merge the changes made to the PowerSync JS TanstackDB demo.

AI Disclosure

I used Claude Opus to help investigate, implement, and verify this work.

[stevensJourney]

Overall I'm happy with the approach here. Left a few comments, mostly nits.

[stevensJourney]

Nit: Can't we use AttachmentRecord here?

[Chriztiaan]

I don't think we can. The types differ slightly (media_type for the tsdb version vs mediaType for common):
I believe this is because the typing for the collection uses the snakecase fields.

[stevensJourney]

Ah I see now!

I think the best fix would be to export some record level type from the common SDK. After checking, the type we have here isn't actually very useful (does not contain the actual columns)

The general type extraction utilities fail for AttachmentTable since this the columns are only defined inside the constructor's super call.

In the common SDK, something like this could work

const ATTACHMENT_TABLE_COLUMNS = {
  filename: column.text,
  local_uri: column.text,
  timestamp: column.integer,
  size: column.integer,
  media_type: column.text,
  state: column.integer, // Corresponds to AttachmentState
  has_synced: column.integer,
  meta_data: column.text
};

/**
 * AttachmentTable defines the schema for the attachment queue table.
 *
 * @alpha
 */
export class AttachmentTable extends Table<typeof ATTACHMENT_TABLE_COLUMNS> {
  constructor(options?: AttachmentTableOptions) {
    super(ATTACHMENT_TABLE_COLUMNS, {
      ...options,
      viewName: options?.viewName ?? ATTACHMENT_TABLE,
      localOnly: true,
      insertOnly: false
    });
  }
}

export type AttachmentTableRecord = RowType<AttachmentTable>;

[stevensJourney]

If we call this in a synchronous transaction invocation, how can this method reliably be async?

[stevensJourney]

It's a nit, and I don't have the strongest opinion on this, but the saveFileTanStack is a bit of a mouthful. Maybe save (just to distinguish it from the base method)?

[Chriztiaan]

Tricky one. Will ponder.