@splayemu this still looks strange, what is :user-room/id? did you mean to get the id from the room? if that so, your output should be like: {:room/user {:user/id id}}, makes sense?

Hi! is it possible to programmatically generate resolvers? I want to try to generate resolvers from a SQL database using foreign keys to resolve between tables

hmm, judging by what defresolver actually creates it looks like I can just create a #:com.wsscode.pathom.connect{:input ... :output ... :resolve ...} map myself, right? 🙂

ahh, just found https://wilkerlucio.github.io/pathom/v2/pathom/2.2.0/connect/shared-resolvers.html

A question about query optimization: I have to two tables, user and organization, and each user has an organization_id that links between the two. I’ve set up some basic resolvers and it works great, but it runs two queries: - SELECT ... FROM user WHERE id = ? to get the user data and organization id - SELECT ... FROM organization WHERE id = ? to get the organization data Is it possible to somehow combine these into

SELECT ... 
FROM user u 
WHERE u.id = ?
INNER JOIN organization o ON u.organization_id = o.id`

I looked at batch resolvers, am I correct that they are more for avoiding multiple calls when you have multiple results from your query, rather than avoiding joins?

and btw, can I just say that Pathom is absolutely amazing 🤯

One more question: is it possible in a resolver to know which outputs are requested? For example, I have a resolver that provides all the data in a table using SELECT * FROM .... But often you only need one or two outputs from a resolver to fulfill the query, and it would be more efficient to do SELECT column1, column2 FROM ... instead. But I couldn’t find anything in the env that say “this is the data I need from the outputs to fulfill the this specific query”, is there such a thing?

and sorry for the wall of questions 😅

@schmee you may be interested in Walkable, which uses Pathom to fetch data from SQL databases: https://github.com/walkable-server/walkable

I gave it a run earlier, but it lacks some things that I need: - no resolver support, so you have to explicitly specify your “N” joins in your queries (dealbreaker for me) - no optimization like the one I described above: it does one query per table