Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
Dan Di Spaltro
@dispalt
@schleumer did you ever figure out that bug with PossibleObject in 2.13?
Horacio
@krabbit93
Hello, I have tried to create a custom NonEmptyListInputType, but i can't yet. I tried using a custom ValidationRule, How can make that?
Pawel
@odwrotnie
Hello!
Are you able to connect Sangria to existing database with auto schema generation?
Ririshi
@Ririshi
Hi everyone, I'm totally new to both Scala and Sangria, and I'm using Sangria in a Play application to create a GraphQL API for our frontend to interface with. I'm using MongoDB as our data storage and am a bit stuck on creating relationships between different models. I currently have a Story case class and an Author case class, and created simple queries for both models to add, find, and update some documents in the MongoDB database. My issue now is with the ability to subquery the author of a story, or the stories written by an author...
Ririshi
@Ririshi

I tried following this tutorial:
https://medium.com/@toxicafunk/graphql-subqueries-with-sangria-735b13b0cfff

But the ids.flatMap(id => ctx.execution.course(id)) part gives me an error that the overloaded flatMap cannot be resolved. I'm using reactivemongo.api.bson.BSONObjectID as Id type, and it seems like there is no flatMap available for a Seq[BSONObjectID]

Greg Fisher
@gnfisher
Hello, it appears that deriveObjectType would convert a Left(error) into a 500 response? Is that accurate?
Yann Simon
@yanns
Are you using sangria with scala 2.11? If yes, please comment: sangria-graphql/sangria#523
Andrii Zarichnyi
@azarichnyi
Good day, people! Sorry, for maybe dummy question, but googling didn’t help. Does Sangria support interfaces that implement interfaces?
3 replies
sinanspd
@sinanspd
ignore my last message... I didn't realize I was in the sangria channel. My bad ... 🤗
Nick Hudkins
@nickhudkins
Hey @yanns , I'd love to help out even if it is just with issue triage for Sangria. Feel free to reach out to me over email if you want to connect (or here!)
4 replies
Yann Simon
@yanns
Hi if someone is looking for something easy to help, we would need this kind of change for all repositories where we release binaries: sangria-graphql/sangria-circe#37
That way we are sure that we emit jvm 8 bytecode.
2 replies
Nick Hudkins
@nickhudkins
Hey @yanns do you have a good list of the official repos now? I know we had to split off for a bit. Happy to spend some time cleaning up
Yann Simon
@yanns
Nick Hudkins
@nickhudkins
Wonderful :), I've got a couple of PRs that I am cleaning up for sangria at the moment, just some bug fixes, and then I can tackle the jvm bytecode stuff.
I'd love to co-ordinate with the maintainers and get a plan together if possible. Even to just make a decision on "Should we support 2.11" etc...
Nick Hudkins
@nickhudkins
Screen Shot 2020-10-22 at 1.21.34 PM.png
Oliver Wetterau
@owetterau
@mkotsur Did you solve your problem with deriveInputObjectType/ deriveEnumTypeissue? I have the same problem ("invalid value: CNil") and am using Circe, too...
Miklos Szots
@smiklos
Hi all,
Recently we've been introducing some bugs in our api when sangira types and circe types don't align. There's this strange duality between those types like enums and scalar aliases that both need to be mapped for sangria and circe. Is there a better approach for this? Can't sangria derive or reuse the circe encoders or the other way around?
Dan Di Spaltro
@dispalt
im not the author but have used it extensively and this is the biggest shortcoming of sangria @smiklos
Nick Hudkins
@nickhudkins
Hey @smiklos and @dispalt sangria by itself has no "allegiance" to any JSON library. I am not sure that I follow what the situation is when your GraphQL types and Circe types don't align. Could you provide a simplified test case to show the behavior and help us understand what you'd be looking for?
Specifically, all things "Circe" and Sangria are handled within the sangria-circe package here: https://github.com/sangria-graphql/sangria-circe and the purpose of the library is only to provide marshalling and unmarshalling of GraphQL types as the schema is being materialized, or input is received.
Miklos Szots
@smiklos
Basically, the sangria-circe module parses json into an AST. This is great, and I understand that this is modular so one can use another marshaller like jackson or so.
The problem arises from the fact that all circe usage is two step, marshalling and encoding the result of the AST into a case class hierarchy.
It's this encoding that doesn't align with Sangria types. I need to both define a case object hierarchy as an enumtype so sangria renders it properly, but I also should not foget to create a circe derivation out of it so case classes can be generated. Lacking that, sangria will validate/parse the json but will crash when case classes are to be created
If I tell Circe how to encode/decode my enum/value class or whatever, I don't feel I should repeate this to Sangria as well. I'ts already done once for circe
the issue is mostly prominent with strong typing (newtype/ extends anyval) because there you need to create a scalar alias for sangria to understand that it's not a nested field (the value in the anyval) but just a regular top level field. Then you need to tell circe how to encode/decode this as well. Same for enums
Nick Hudkins
@nickhudkins
Have an example I can take a look at?
Or, any chance you could fork: https://github.com/sangria-graphql/sangria-akka-http-example and recreate the issue? The only time Circe and Sangria "interact" is when it is being materialized. Are you using Json WITHIN your resolvers?
Miklos Szots
@smiklos
Here is one
case class ResultData(resultId: ResultId)

object ResultId {

  //Already derived it as a string
  //This is a factory for creating ResultId from String
  implicit val encoder: Encoder[ResultId] = Encoder.encodeString.contramap(_.id)
  implicit val decoder: Decoder[ResultId] = Decoder.decodeString.map(ResultId(_))

  //Now I repeat myself
  //This is also a factory for creating ResultId from String
  implicit val graphQlType = ScalarAlias[ResultId, String](
    StringType,
    _.id,
    id => Right(ResultId(id))
  )
}

case class ResultId(id: String) extends AnyVal
Nick Hudkins
@nickhudkins
Ah, ok, so you would hope that by defining the ScalarAlias, that you'd get your encoder / decoders for whatever marshalling library you're using correct?
Miklos Szots
@smiklos
well, that would be ideal isn't it. Not whatever, I'm more than happy if it only supports circe (;> )
Nick Hudkins
@nickhudkins
Haha :) ok, let me give some thought to that.
Miklos Szots
@smiklos
We could possibly create a conversion from sangria type to circe or the other way around. The tricky thing in both cases is that both sangria and circe is more than happy to compile when using auto derivation without any of these extra implicits. a bit better solution would be to be able to derive one of the encoder/decoder pairs from the other. A lot better solution would be when sangria generates marshaller, it would auto derive circe encoders
Nick Hudkins
@nickhudkins
ya, we already "have" to do this as we marshall / unmarshall input and output types: https://github.com/sangria-graphql/sangria-circe/blob/master/src/main/scala/sangria/marshalling/circe.scala#L92-L104
Yann Simon
@yanns
I'm not 100% but circe should never be used when parsing the query. The json library is only used when creating the payload to send over the wire.
Nick Hudkins
@nickhudkins
Absolutely. I think @smiklos's use case is that, is that if a custom scalar exists, you might need to convert to and from... within your application
outside of accepting it as input, and rendering it as output
My "does this seem like something Sangria (or json support for sangria) should handle" screams... no, because Sangria doesn't have any care about that.
Miklos Szots
@smiklos
even more often we use scalar aliases. trying to keep the input already prevalidated by enfocing contstraints (like strong types, lengths of string etc).
It just feels strange that I need to tell circe that it should encode/decode those types differently when I already did tell sangria about it
I totally understand the separation of concerns here but that doesn't fix the usability of it. It just feels strange. Somehow being generic clashes with being convenient
Nick Hudkins
@nickhudkins
I still am not sure what the use case is here
in your case, let's say you don't define the encoder and decoder...
if a resolver indicates a field as a ResultId.graphqlType, and you return a string from said resolver, it will be coerced according to your toScalar function id => Right(ResultId(id))
Miklos Szots
@smiklos
Then circe will believe that I sent the input json as
{
 resultId: {
   id: "something"
}
instead of 
{
resultId: "something"
}
and so it will fail
Nick Hudkins
@nickhudkins
I think I'm back to being confused :) lol
Miklos Szots
@smiklos
my use case is that I want to abuse scala aliases because that's the recommended approach according to the docs. Turning simple scalars to narrower/valid types.
But because of that, I also need to tame circe derivation at the same time. Have I always accepted Strings and numbers, it would all be fine
:D
Nick Hudkins
@nickhudkins
Just to be clear, we are talking about InputTypes right?
Miklos Szots
@smiklos
yes
Nick Hudkins
@nickhudkins
ok, so then I believe you're not looking for ScalaAlias, but instead, need the FromInput type classes