3 ms·
Neat! How difficult would it be to extend this to SQL like query languages like Hasura and PostgREST (via Supabase)? - https://hasura.io/docs/latest/api-refere
by cpursley 3y ago
Neat! How difficult would it be to extend this to SQL like query languages like Hasura and PostgREST (via Supabase)?
- https://hasura.io/docs/latest/api-reference/graphql-api/query https://hasura.io/docs/latest/api-reference/graphql-api/quer...
- https://postgrest.org/en/stable/references/api/tables_views.html#read https://postgrest.org/en/stable/references/api/tables_views....
^ The advantage would be, these tools handle authorization.
- jcjc712 3y agoIt shouldn't be difficult, if we provide many examples and the db/table schema the agent can provide an accurate response
- aazo11 3y agoInteresting. So far we have been focused on allowing non-technical users to self-serve from enterprise data warehouses. It might be possible to enable this scenario with a simple addition to the NL-2-SQL engine to translate the generated SQL to API calls. If that does not work, a custom imeplementation of the NL-2-SQL module would def solve this. Do you have a specific use-case in mind? Would love to collaborate on adding it to the open-source library if you are open to it.
- cpursley 3y agoMostly my concerns are around authorization (who can access what) and those two tools handle that before generating a database query. So maybe the approach would be to go from natural lang -> SQL (as you do now) then to Hasura's or PostgREST's specific query syntax (which are already pretty SQL like). And specifically with Hasura, since it's GraphQL - you can get all the available types. But that might all be to far out of scope of what you're trying to do.
- DaiPlusPlus 3y agoRe: security - assuming your RDBMS supports row-level security then you should be fine as-is - otherwise let users only query VIEW objects with security filters baked-in to them.