Skip to content

Raw table improvements#855

Open
simolus3 wants to merge 4 commits intomainfrom
raw-table-updates
Open

Raw table improvements#855
simolus3 wants to merge 4 commits intomainfrom
raw-table-updates

Conversation

@simolus3
Copy link
Contributor

This adds support for new raw table features for version 0.4.11 of the core extension. For more context, also see the Kotlin PR.

Raw tables can now be defined in two ways:

  1. With the put and delete statements, like before.
  2. By passing a tableName describing the name of the table in the local schema, which will make the sync client infer the put and delete statement (so they're optional, but can still be used to customize them).

This also adds RawTable.clear, which has been added in the previous core extension update.

@changeset-bot
Copy link

changeset-bot bot commented Feb 17, 2026

🦋 Changeset detected

Latest commit: a6df8e5

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 9 packages
Name Type
@powersync/common Minor
@powersync/node Minor
@powersync/capacitor Minor
@powersync/react-native Minor
@powersync/web Minor
@powersync/adapter-sql-js Patch
@powersync/op-sqlite Patch
@powersync/tanstack-react-query Patch
@powersync/diagnostics-app Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

const customSchema = new Schema({});
customSchema.withRawTables({
lists: {
tableName: 'lists'
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is it possible for tableName to be optional here? It looks like there might be many cases where the object key and tableName would be the same.

Copy link
Contributor Author

@simolus3 simolus3 Feb 18, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've considered that as well.

In the end, I wanted to avoid this because existing documentation explicitly states that the key (lists) doesn't have to match the name of the local table because it only affects for which tables the custom statement would be used. So changing that now would assign new meaning to that same key which might be confusing.

Additionally, we need some type-safety to express that either:

  1. A table schema is given, in which case put and delete are optional.
  2. Otherwise, put and delete are required.

If tableName was optional, lists: {} would be a valid definition.

I also want to make passing a schema with the table name an explicit choice since it expresses that the default inferred statements can be used (meaning that the user expects no data transformations in custom statements to be necessary). So this should be syntactically different from the developer just forgetting the put and delete statements.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Tables can now be defined as withRawTables(users: { schema: {} }) to avoid specifying the name twice.

Still a bit of syntactic overhead there, but that might be fine to point out that schema can be customized further.

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.

3 participants