Feature request: Table filters for tabular persisters

[jakubriedl]

Hi, first of all thanks for amazing work.

Problem / use-case

Is your feature request related to a problem? Please describe.

Let me start with describing our use case. We are dev tool platform and most of data for our users are organized in "branches". And we want to use TinyBase to synchronize these between browsers, IDEs, Cloudflare Workers/Durable Objects and Postgres.

Because data are thanks to the branches logically partitioned we want to create TinyBase Store per branch. Because as user works on one branch we don't need any other data. Also companies may over time collect a lot of abandoned branches that are unused so scoping per branch will keep it reasonably small.

But I believe that this is might be quite common, as things are often organized in projects, rooms, organizations, ...

Feature request

Describe the solution you'd like

It would be great to be able to define filters on table definitions (that logically map to something like where branchId = "xyz") when creating persister, which would instruct it what data it should load for given table.

If I understand the source code right the condition would come here in loadTable command but also on other places where currently all rows get deleted (eg here and here)

Alternatives

Describe alternatives you've considered

Unfortunately we haven't found any alternative that would allow us to synchronise only part of tables

[jakubriedl]

@jamesgpearce I've tried to implement this in #234. There is still some failing documentation test I can't figure out, and probably needs more testing, but would you please consider this feature? We'd really appreciate it and would save me maintaining a fork.

[jamesgpearce]

For sure! This would be cool and I can take a look at the PR, definitely.

[mohsinhijazee]

This would be really really useful in so many cases. Imagine 1000 devices on the field with some data collection for some environmental campaign or similar. Now each device might be gathering few thousand records but with no scoping, this means each device is going to have 1000x1000 records from everyone else. But that's not useful and a waste of storage and bandwidth even more so when such one user does not care neither need all that data on their device about what all other 999 users are doing/collecting/logging.

[jamesgpearce]

Coming in v6.1!