-
Notifications
You must be signed in to change notification settings - Fork 146
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
fix (sync-service): let Postgres handle user-provided root table name #1776
base: main
Are you sure you want to change the base?
Conversation
packages/sync-service/lib/electric/postgres/inspector/direct_inspector.ex
Outdated
Show resolved
Hide resolved
…on from table name.
✅ Deploy Preview for electric-next ready!
To edit notification comments on pull requests, go to your Netlify site configuration. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I gave a brief look through (gotta run to airport in a sec) and it looks great.
One thing we talked about yesterday also is including the sql statement in errors we send back — I'll make a separate issue for that for some follow-on work — #1790
assert %{"root_table" => ["table not found"]} = Jason.decode!(conn.resp_body) | ||
assert %{ | ||
"root_table" => [ | ||
~s|Table "nonexistent" does not exist. If the table name contains capitals or special characters you must quote it.| |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nice error message!
This PR fixes #1764 according to the approach that was decided by @KyleAMathews, namely to adhere to Postgres' way of handling identifiers. Therefore, this PR modifies Electric such that it passes the user-provided root table to Postgres which then returns the actual relation (i.e. schema and table name). Which we then use throughout the rest of the code as before.
We extended the ETS inspector with a write-through cache that caches the relation. For any incoming request, it tries to fetch the relation for that table from the cache. If not found, it loads it from PG and stores it in the cache. Note that many table name spellings can refer to the same relation, e.g.
users
,USERS
,public.users
, etc. all refer to the same relation{public, users}
. For each different spelling, we will load the relation from PG and store it in the cache. Subsequent requests then load it from cache. We also cache the inverse (mapping relation to the different table names) in order to efficiently clean up.