Data awareness

When a column's values matter, SQLly can use them to make the next suggestion more useful.

The schema tells SQLly what a column is; data awareness helps it learn what the column contains. With carefully bounded value introspection, completion can help on the right-hand side of a WHERE clause and let you work with a readable name instead of an opaque id.

Reading data is different from reading schema

Schema is small, cacheable, and harmless to fetch in the background. Data is none of those things, so value completion plays by stricter rules:

• You ask for it. Value lookup is a deliberate action - Ctrl+Shift+Space, or Table Column Value Autocomplete from the menu. SQLly does not query your data because you paused while typing.
• Only in a value slot. The request only resolves when the cursor is somewhere a value for a known table and column belongs. If it cannot resolve one, it says so rather than guessing at a query.
• Distinct and limited. The lookup is a SELECT DISTINCT capped at 100 values, written in your engine's own syntax (TOP, LIMIT, or FETCH FIRST).
• Cached, and bounded. Results are cached per connection, database, table, and column, and the cache evicts least-recently-used entries - so a long session across many columns does not grow without limit, and asking twice does not query twice.
• Off the keystroke path. The fetch runs on a background task with a request token, so a stale answer can never overwrite the menu you are looking at.

Not connected to a database, or the column cannot be resolved? You get a plain status message rather than a silent non-event.

In this section

• Table value introspection — Bring real, distinct values into completion so a WHERE clause is less of a guessing game.
• Foreign key / name interchangeability — Look up a familiar name instead of memorizing an id; SQLly follows the relationship for you.