Custom resolving of child object that maps to SQL table about join-monster HOT 15 CLOSED

try this in your type definition:

{
  // this will create a hole where id will still be used to create the spine.
  where: () => 'FALSE',
}

from join-monster.

Hmm doesn't seem to work.

{
  Relationship: {
    sqlTable: 'relationships',
    uniqueKey: 'id',
    fields: {
      otherUser: {
        where: () => 'FALSE',
        resolve: () => ({ id: 222 })
      }
    }
  }
}

from join-monster.

This is what type looks like.

type Relationship {
  id: Int
  state: String
  otherUser: User
}

from join-monster.

@tonyxiao for fields you can just define the resolver yourself -- as long as sqlColumn isn't defined on the field -- it won't attempt to fetch that column. Remove the where.

from join-monster.

@tonyxiao I see whats happening -- I stared at your code a little bit longer. Let me see if I can find a way to bypass the assumption join monster is making here in your use case.

from join-monster.

@dreamcodez That works for scalar fields, but not for object fields.

from join-monster.

Works for scalars
https://github.com/stems/join-monster/blob/ec920cdcb69b6c79a72ff3325b712ca1810f1244/src/query-ast-to-sql-ast/index.js#L107

Does not work for objects
https://github.com/stems/join-monster/blob/ec920cdcb69b6c79a72ff3325b712ca1810f1244/src/query-ast-to-sql-ast/index.js#L95

from join-monster.

@tonyxiao Yeah this seems like it will be a common use case. Just because as ObjectType is tagged with sqlTable does not necessarily mean it should be handled by JM in all fields in the schema. We need an option to opt-out. I'll think about the best way to add this in for the next release.

For now, you can fork and monkey-patch it in. You can add a property like so

{
  Relationship: {
    sqlTable: 'relationships',
    uniqueKey: 'id',
    fields: {
      otherUser: {
        // tell joinMonster this is a no-op
        jmIgnore: true,
        resolve: () => ({ id: 222 })
      }
    }
  }
}

And then you can open query-ast-to-sql-ast/index.js and go to line 53 and add the following block.

  if (field.jmIgnore) {
    sqlASTNode.type = 'noop'
    return
  }

This will tell joinMonster's AST to not compile any SQL for that branch of the schema.

Keep in mind that the code in the src/ directory is compiled by babel so changes to the code need to eventually be built and propagated to dist/.

from join-monster.

@acarl005 actually it's still useful to be able to specify stuff like sqlDeps. The columns here can actually be important for resolutions of custom objects.

{
    sqlTable: 'relationships',
    uniqueKey: 'id',
    fields: {
      otherUser: {
        sqlDeps: [ 'user_id', 'target_id' ],
      }
    }
  }

from join-monster.

Hm. I'm a little bit confused. You say you want a "completely custom resolver for the child." I assume that means you want to hit the network on your own. By "completely custom," are you saying you'll be writing your own SQL query? If so, joinMonster won't be querying that table at that level in the schema so specifying sqlDeps can't really be done. You will have to inspect the resolveInfo on your own and execute your own logic for whether or not to include certain columns in your custom query.

On the other hand, maybe thats not what you mean. Maybe you still want Join Monster to join on the user table again and get the data, and then run a resolve function on the data it brings back. If thats the case, its already possible. Even if joinMonster fetches a field for you, it won't cause any resolver to be ignored. It just allows you to omit it in many cases.

from join-monster.

@acarl005 in addition to having join-monster complete ignore an object field (which should totally be an option), what I meant to say is that it's also useful to have computed object fields, not just computed scalar fields, that have depend on other fields. (Think the fullname example).

In my particular case, I want to retrieve otherUser object based on the values of user_id and target_id columns, and I want to make sure those values are available on the parent argument in the resolver.

from join-monster.

Ah okay now I understand. You do want to write your own resolver, but that resolver still needs access to columns from the parent object. Yes, I agree, this is an important capability! I'll get this into the next release. Or I'll happily accept a PR if its more urgent.

from join-monster.

Correct! Will try my best to submit a PR next week. By the way (let me know if this is better as a separate issue), will join monster batch across multiple calls in the same request? Here's an example

type User {
  pictures: [Picture]
}
type Picture {
  url: String
}
type RootQuery {
  searchUsers(term: String): [User]
}

// via graphql-tools
const RootQuery = {
  searchForUsers: () => [...] // Do something to retrieve list of matching user ids from outside of SQL
}
const User = {
  sqlTable: 'users'
  fields: {
    picture: {
      sqlJoin(userTable, picturesTable) {
        return `${userTable}.id = ${picturesTable}.user_id`
      },
      resolver(parent, args, context, resolveInfo) {
        return joinMonster(resolveInfo, {}, sql => {
          return knex.raw(sql)
        })
      }
    }
  }
}
const Picture: {
  sqlTable: 'pictures'
}

and I make the following graphql query

{
  searchUsers(term: "hello") {
    picture {
      url
    }
  }
}

Is it possible for joinMonster to batch the requests like the following instead of one request per user?

select url from pictures
inner join users
on pictures.user_id = users.id
where users.id IN ($idsRetrievedFromSearch)

from join-monster.

Yes, you can do this with sqlBatch. Here is the section on this in the documentation.

from join-monster.

Newest version includes two new field options: jmIgnoreAll and jmIgnoreTable. jmIgnoreAll will ignore all the join monster properties. jmIgnoreTable will ignore only the sqlTable tag on the object type, allowing you to specify sqlDeps instead.

This isn't in the documentation yet but I'll update that soon.

from join-monster.