Referencing external tables in .drift files

[galacticgibbon]

I'm using powersync raw tables which requires creating triggers/migrations that reference some tables managed by them

e.g. trigger: https://docs.powersync.com/usage/use-case-examples/raw-tables#capture-local-writes-with-triggers
and data migrations: https://docs.powersync.com/usage/use-case-examples/raw-tables#adding-raw-tables-as-a-new-table

I'd like these triggers to be part of my drift schema for type safety and automated migrations, but I run into lint errors because they reference tables that drift doesn't know about, and test errors from the generated tests from make-migration when applying the data migrations from ps_untyped

I was just wondering if there's some existing solution or if you have ideas on solving them. Perhaps a way to quiet lints, or declare tables in .drift files that won't be committed in the DB, something along those lines.

[simolus3]

The thing about these external tables (I assume you're referring to powersync_crud) is that they're not real database tables (if they were, you could also just write a regular CREATE TABLE statement in a .drift file for them and then configure your migrator to not create those tables).

I have added analysis support for these virtual tables in 5724986, so with the next release you could add powersync to the list of enabled modules and drift would then recognize the powersync_crud table as well as some related functions.

[galacticgibbon]

@simolus3 Well, I actually ran into what I think was a bug with raw tables but I didn't have the time to go properly investigate (https://discord.com/channels/1138230179878154300/1424046451238899926)

So in the end I ran with my own custom raw table setup using triggers ps_data__

and just taking the 2x storage overhead hit, at least until raw tables are less experimental.

So actually my triggers run on ps_data, and since it's non-standard I don't expect you to patch that specifically, but what I was hoping was that there could be a solution which is generic. i.e. I could define some table in .drift files, maybe annotate it with something like @external and drift uses that for its type analysis, but doesn't include it in the output.

Not sure how manageable that is, but that would be quite flexible. Then again, not sure how many people have this usecase.

[galacticgibbon]

If that would not justify the effort, a way to silence lints on specific entities could be nice as well.

[galacticgibbon]

That being said, I did just notice that successive rebuilds on the same file are ignored and don't trigger the analysis warning, so it's kind of a non-issue to be honest.

[simolus3]

The next drift version will introduce a known_tables builder option which allows defining CREATE TABLE statements that drift assumes to be available. That should silence the warning if the triggers only reference columns mentioned in that CREATE TABLE statement.

[galacticgibbon]

You're the goat