Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
Alexej Haak
@Daxten
to somehow emulate a Union/Interface
I'm also not sure if I can write the mapping of InputFields to Scala class by hand somehow? There seems to be a lot of macro / reflection magic involved here?
Alexej Haak
@Daxten
Okay this is cool imo, I added implicit conversions for SumEmulationOfUnionType => UnionType and vice versa and all the macros etc. work with the implicit conversions
At least I think... it compiles so far lets say :P
Alexej Haak
@Daxten
meh no that doesn't work
so anyway to create an Input type by mapping an already existing InputType? Or by doing the deserialization myself (e.g. MyClass(arg("a"), arg("b")))
Alexej Haak
@Daxten
Okay now I understand one thing more: deriveInputObject actually derives 2 things, the InputObject and FromInput
I thought the FromInput stuff is happening "somehow" in InputObject... so with these 2 combined I can write my own deserialization, nice!
Christian Kjær
@Tehnix
Does anyone have good examples of setting up UnionTypes? Been running into UndefinedConcreteTypeError: Can't find appropriate subtype of a union type and for the love of god I can't find a fix for it :/
Christian Kjær
@Tehnix
...nevermind, apparently I was returning it in a effect which we'd normally do, but it fail until runtime with a very unhelpful error message 😅
Daan Debie
@DandyDev
Hey all! I have a question to which I couldn't find the answer: is Sangria compatible with Scala 3 yet? Is it on the way?
Yann Simon
@yanns
@DandyDev there were no efforts into porting Sangria to Scala 3 yet. If you are motivated, you're welcome to help. Development efforts are coordinated on #sangria-dev.
Shohei Shimomura
@sh0hei
@yanns @DandyDev I plan to make sangria compatible with scala3 :thumbsup: Currently working :muscle: Welcome your help at any time.
1 reply
Yann Simon
@yanns

@yanns @DandyDev I plan to make sangria compatible with scala3 :thumbsup: Currently working :muscle: Welcome your help at any time.

🤩

alex-gaiduchok
@alex-gaiduchok

hey guys, need your advice:
switched sangria to 2.1.0
PR looks like this

    "org.sangria-graphql" %% "sangria" % "1.4.2" =>  "2.1.0",
    "org.sangria-graphql" %% "sangria-relay" % "1.4.2" =>  "2.1.0", 
    "org.sangria-graphql" %% "sangria-circe" % "1.2.1" =>  "1.3.1",
    "org.sangria-graphql" %% "sangria-slowlog" % "0.1.8" =>  "2.0.1",

nothing else was changed.

And faced a memory leak 6 hours after the update (maybe related to traffic).

Maybe someone also faced mem leak at sangria 2.10 ?

alex-gaiduchok
@alex-gaiduchok
platform is graalvm 20
Yann Simon
@yanns
running with this version since months with high traffic, and we have no memory leak about it.
But the leak could also come from how you instantiate your schema...
The better to find it is to check the memory, for example with java mission control. Altough I don't know which tools will work with graalvm.
alex-gaiduchok
@alex-gaiduchok
sure, I will try to look at this problem with the profiler, just want to be sure that nobody faced/solved this problem, before dive deeper in debugging
sjuyal12
@sjuyal12
Hey! I want to write a graphql mutation using sangria which returns a List. However, currently I only can figure out writing mutations which return an object not a list of objects. Like :- val MutationType: ObjectType[GraphQLContext, Unit] = ObjectType("Mutation", fields[GraphQLContext, Unit](
And then val schema: Schema[GraphQLContext, Unit] = Schema(QueryType, Some(MutationType))
Yann Simon
@yanns
Your mutation could contain a Field("results", ListType(ObjectType).... Does it work?
Witold Soczek
@v-tec2706

Hi, I have a question about deferred resolution. Is there a way to run multiple deferred resolutions one by one? What I want to achieve in resolver function is:

for {
   idsA <- deferredFetchA
   idsB <- deferredFetchB
  selectedItems <- do sth with idsA and idsB
} yield anotherDeferredFetch(selectedItems)

I was trying to play with DeferredValue(...) but with no success

Yann Simon
@yanns
See https://sangria-graphql.github.io/learn/#deferred-value-resolution
In your schema, use your own class that extends Deferred.
In your DeferredResolver, you have access to all your accumulated Deferred instances. Based on this input, you can choose how to resolve them. And this can be one by one if you want to.
Yann Simon
@yanns
If you use Fetcher, you might be interested in this change that allows setting the max concurrency: https://github.com/sangria-graphql/sangria/pull/454/files
This PR would need help (rebase on last version I guess) so that it could be integrated.
Witold Soczek
@v-tec2706
thank you @yanns! I'll try that
Justin Reeves
@justinallenreeves

Currently getting an error when returning a large page of results Fetcher has not resolved non-optional ID ‘<SOME_ID>’
I’ve looked at the ids thrown by the error and found the objects/entities they refer to (it’s a nested object inside the object being queried) and they exist
I can do a more narrow query that filters for that specific object and get page with 1 result.
It so far only seems to blow up when I have to many.

Perhaps this is an issue with a the Future for the Field being queried is resolving before the defered resolver finishes?

Yann Simon
@yanns
@justinallenreeves is it a new issue? In which version do you observe that?
Justin Reeves
@justinallenreeves
We’re on 2.0.0 but I’m not sure it’s a bug with Sangria.
I’ve been playing with page sizes all morning trying to reproduce but it looks like it’s related to the data.
I neglected to included the exception, it’s a sangria.execution.deferred.AbsentDeferredValueError
Alexej Haak
@Daxten
FetcherBasedDeferredResolver.scala:245 there is no way to give Fetchers a name or sth right now if understand correctly... I have like 10 fetchers in my project and if one throws that error it's pretty hard to debug which one
Since the thread trampolining removes the stacktrace
Yann Simon
@yanns
Please feel free to add issues with as much info as possible. And we can also help you to make your first PR if you like ;)
Greg Fisher
@gnfisher
I am running into an issue where Sangria is not generating a type as I would like. I've got a Validated[A] type with a GraphQLOutputTypeLookup[Validated[A]] defined thusly:
  implicit def validatedType[A](
      implicit lookup: GraphQLOutputTypeLookup[A]
  ): GraphQLOutputTypeLookup[Validated[A]] =
    new GraphQLOutputTypeLookup[Validated[A]] {
      def graphqlType: OutputType[Validated[A]] =
        ObjectType(
          s"Validated${lookup.graphqlType.namedType.name}",
          fields[Ctx, Validated[A]](
            Field("value", lookup.graphqlType, resolve = _.value.value),
            Field(
              "fatal",
              ListType(FatalType),
              resolve = _.value.status.fatal
            ),
            Field(
              "warning",
              ListType(WarningType),
              resolve = _.value.status.warning
            )
          )
        )
    }
The issue is having both a Validated[String] and Validated[Option[String]]. If only one or the other is present, it works as expected ( in elm I get a Maybe String in the generated graphql object). But if both are present, only one is generated. So in my case, only a ValidatedString type exists, and its not a Maybe String in elm land.
Validated looks like this:
case class Validated[A](value: A, status: Status) {
  def map[B](f: A => B): Validated[B] =
    copy(value = f(value))
}
I think it has something to do with how the type name is generated with this line: s"Validated${lookup.graphqlType.namedType.name}",
so when both are present one overwrites the other and only one version is created.
and that is because lookup.graphqlType.namedType reaches into option to get the wrapped type
Greg Fisher
@gnfisher
I'm trying to find a way to know if the A is an Option so I can insert that into the name...
Greg Fisher
@gnfisher
I am still unable to discover a way to resolve this issue, if anyone has any ideas, I'd appreciate it!
Yann Simon
@yanns

Yes different types should have different names.
A way to fix that would be use a trait like:

trait GraphQLTypeName[A] {
  def typeName: String
}
implicit def validatedType[A](
      implicit lookup: GraphQLOutputTypeLookup[A],
      implicit typeName: GraphQLTypeName[A]
  ): GraphQLOutputTypeLookup[Validated[A]] =
    new GraphQLOutputTypeLookup[Validated[A]] {
      def graphqlType: OutputType[Validated[A]] =
        ObjectType(
          s"Validated${typeName.name}",

Then you would create 2 instances of GraphQLTypeName :

implicit val stringGraphQLTypeName: GraphQLTypeName[String] = ...
implicit def optionGraphQLTypeName[A]: GraphQLTypeName[Option[A]] = ...
Mark Tomko
@mtomko
I'm trying to define an ObjectType and I'd like to put some validation in so that after I've parsed the fields, I can check the value and return a sensible error if they're not compatible, before I try and construct the actual object this represents. Where does logic like that usually live?
Yann Simon
@yanns
@mtomko I'm not sure I understand your question. ObjectType are typed. The scala compiler should check the fields' types for you?
Mark Tomko
@mtomko:matrix.org
[m]
I'm not talking about type checking, I mean consistency.
In this case, the two fields would be dates, and they're not valid unless one is before the other (ie, from is less than or equal to to)
Mark Tomko
@mtomko:matrix.org
[m]
:point_up: Edit: In this case, I'm not thinking of type checking, I mean consistency.
:point_up: Edit: I'm not thinking of type checking, I mean consistency, I should have been more clear.
Yann Simon
@yanns
The consistency could be checked in the data model no? Why do you need this business logic in GraphQL?
If you want to do something in GraphQL, you could add a ValidationRule to your executor.
Mark Tomko
@mtomko:matrix.org
[m]
In this case, the Scala type we're mapping to GraphQL has strict rules prohibiting to prevent an invalid object from being constructed, so I was hoping to be able to put a check in to return a user-facing error rather than relying on the type's constructor to return an error (which would not be suitable to display for a number of reasons). I could add a type in between, but that feels sort of heavy-weight. I can look into a ValidationRule but it also seems not scalable to put validation rules in the executor that affect just one of a myriad number of types that our GraphQL represents.