v0.7.3

• Description formatting/parsing is updated based in the changes in the reference implementation (#155). More places of the query now preserve the comments. For instance all trailing comments within a section set and at the end of the document are preserved and rendered.
• Ensure that the result of deferred value resolution has the same size as the deferred list (#154).
• During macro-based derivation, default value should never be a null for an optional arguments (#153).
• Executor now properly handles undefined values (like null and None) even if GraphQL type is not null (#152)

v0.7.2

• Transitive types are now collected for all types provided via additionalTypes to a schema definition (#149).
• ObjectType.withInstanceCheck provides an easier way to customize an instance check on ObjectType (#148).
• Enumeration derivation macro should now only collects instances of Enumeration#Value (#151).
• Ensure that all unreferenced types are collected during the schema extension.
• sangria.ast.Type.namedType helper method.

v0.7.1

• Provide extendSchema utility function (#113). This feature allows you to extend existing schema with additional types and existing types with additional fields. It may be very useful for client-side tools and for server implementations in cases where parts of a schema are dynamically generated or coming from external sources (like database).

  Here is a small example of how you can use it:

  val schema: Schema[Ctx, Val] = Schema(...)
  
  val schemaExtensions =
    graphql"""
      extend type Human {
        pet: Animal @loadPetInfo
      }
  
      interface Animal {
        name: String!
      }
  
      type Dog implements Animal {
        name: String!
        nickname: String
      }
  
      type Cat implements Animal {
        name: String!
        age: Int
      }
    """
  
  val myCustomBuilder = new DefaultAstSchemaBuilder[Ctx] {...}
  
  val extendedSchema = 
    schema.extend(schemaExtensions, myCustomBuilder)  

  Just like with AST-based schema materialization, you can provide a custom schema builder which allows you to control most of the aspects of generated parts of the schema.

• Handling of more than one ProjectionName for one field (#146).

• Updated context propagated only to siblings (#145).

v0.7.0

• Initial CATs (Compatibility Acceptance Tests) support (#142). The test suite itself is still work-in-progress, but sangria includes an integration which executes all currently available test cases.
• IDL (schema definition) syntax parsing and rendering (#137, #62)
• AST-based schema materializer (#139, #115). This feature may be very useful for different tools that need to create an executable schema based on IDL definitions. Almost any aspect of generated in-memory schema representation can be customized via custom implementation of AstSchemaBuilder. This feature is already used in sangria itself for CATs (Compatibility Acceptance Tests) integration. At the moment default implementation of AstSchemaBuilder treats comments that start with ## as a field/object/argument description.
• Partial resolve Actions (#140). This change introduces 2 new Actions that can be returned back from a resolve function: PartialValue and PartialFutureValue. This allows you to return a list of errors in addition to a successfully resolved value (which may contain only partial result due to the errors).
• Preserve comments during the AST parsing (#105). Most of the AST classes got comment Option[Comment] field. It can be very useful for query formatting because QueryRenderer also got support for comments and able to render them.
• Include execution path in error objects (#143). This may be helpful for client side tools that would like to analyze error messages and programmatically use them in some way. This is a minor braking change since field property on error is removed in favor of new path property which is a list.
• Introspection-based schema materializer now also uses more advanced IntrospectionSchemaBuilder (similar to the AST-based one) instead of MaterializationLogic, which is now removed. This introduces a minor breaking change, but in a long run IntrospectionSchemaBuilder will provide much more flexibility.
• Add comment/directive support in the introspection-based schema renderer (#136).
• Validation: improving overlapping fields quality (#133)
• Deprecated directive (#132)
• New directive locations (#131)
• Default values should be in GraphQL format (introspection) (#141)
• Added support for case objects defined in companion object (#135). Big thanks to @joprice for contributing this improvement!
• SchemaRenderer now has improved default value rendering
• Execution path now got it's own class ExecutionPath (which is now used instead of simple Vector[String]). This introduces a minor breaking change.

v0.6.3

• Marshaling for Amazon Ion data format is introduced. Amazon Ion is a richly-typed, self-describing, hierarchical data serialization format offering interchangeable binary and text representations.

  You need following dependency to use it:

  "org.sangria-graphql" %% "sangria-ion" % "0.1.0"

  In order to use Ion marshalling, you need an implicit instance of IonSystem in scope as well:

  import sangria.marshalling.ion._
  
  implicit val ionSystem = IonSystemBuilder.standard().build()
  
  val result: Future[IonValue] = Executor.execute(schema, query)

• Marshalling API is updated to v0.2.1. It introduces a minor breaking change. This change introduces performance improvements to scalar value marshalling and gives much more flexibility in terms of the type of marshaled values.

  ResultMarshaller now able to communicate it's natively supported capabilities to a ScalarType via MarshallerCapability. A set of standard marshaller capabilities were introduced:

  • DateSupport - Marshaller supports java.util.Date natively.
  • CalendarSupport - Marshaller supports java.util.Calendar natively.
  • BlobSupport - Marshaller supports large binary objects in form of Array[Byte] natively.

  This still requires you to create a custom scalar types (for dates, blobs, etc.), but it gives you an ability to generically use native features of underlying data format.

  ScalarType now also able to communicate back to marshaller via ScalarValueInfo. This can be used, for instance, to represent an Array[Byte] as a clob type instead of blob in formats that support both of them (like Amazon Ion).

• Include possible field, argument, type names when validation fails (#126).

• Deepen introspection query from 3 levels to 7 (#128).

• Improve validation error message when field names conflict (#130).

• Interface hierarchies are not correctly rendered with SchemaRenderer (#125).

• Updated parboiled to v2.1.3

v0.6.2

This version is fully compatible with "April 2016" version of the GraphQL specification.

• Return type overlap validation (#124) (spec change).
• deriveContextObjectType/deriveObjectType do not work with Option arguments in some cases (#123)

v0.6.1

A minor maintenance release to keep up with the spec changes.

• Field order in the result now reflects field order in the query (according to the spec) for all marshalling libraries that support field ordering (#99) (spec change).
• Directive locations field replaces onOperation, onFragment and onField (#119) (spec change).
• Low-level marshalling API is improved: it's now possible to use efficient map builders (which also able to preserver an order of the fields). This improves serialization performance and minimizes memory footprint. All marshalling libraries already take advantage of this API.
• SchemaRenderer prints duplicated fields for a type that implements an interface (#122)

v0.6.0

• Macro-Based GraphQL Type Derivation (#120). See "Macro-Based GraphQL Type Derivation" section of the documentation for more info.

• Prepared Queries (#118). See "Prepared Queries" section of the documentation for more info.

• Executor.execute now returns Future with failure if error happened before query execution (#109). It can be extremely helpful when you need to take some action or produce different result in case of error. Typical example is returning different HTTP status code.

  CAUTION: breaking change and action needed! Since things like validation errors and errors in query reducers are now explicitly returned as a Future failure and not as a successful result, you need to take some action to handle them. In order to migrate, all you need to do is to add following recover:

  Executor.execute(schema, query).recover {
    case error: ErrorWithResolver ⇒ error.resolveError
  }

  recover function will make sure that all of the errors, that were previously handled internally in Executor, are now properly handled. Code above will produce exactly the same result as before. resolveError produces a valid GraphQL response JSON and will use custom exception handler, if you have provided one.

  This new approach to error handling gives you much more flexibility. For example in most cases it makes a lot of sense to return 400 HTTP status code if query validation failed. It was not really possible to do this before. Now you able to do something like this (using playframefork in this particular example):

  executor.execute(query, ...)
    .map(Ok(_))
    .recover {
      case error: QueryAnalysisError ⇒ BadRequest(error.resolveError)
      case error: ErrorWithResolver ⇒ InternalServerError(error.resolveError)
    }

  This code will produce status code 400 in case of any error caused by client (query validation, invalid operation name, etc.).

  Errors that happened in a query reducer would be wrapped in QueryReducingError. Here is an example of returning custom status code in case of error in the query reducer:

  val authReducer = QueryReducer.collectTags[MyContext, String] {
    case Permission(name) ⇒ name
  } { (permissionNames, ctx) ⇒
    if (ctx.isUserAuthorized(permissionNames)) ctx
    else throw AuthorizationException("User is not authorized!")
  }
  
  Executor.execute(schema, queryAst, userContext = new MyContext, queryReducers = authReducer :: Nil)
    .map(Ok(_))
    .recover {
      case QueryReducingError(error: AuthorizationException) ⇒ Unauthorized(error.getMessage)
      case error: QueryAnalysisError ⇒ BadRequest(error.resolveError)
      case error: ErrorWithResolver ⇒ InternalServerError(error.resolveError)
    }

  HTTP status code would be 401 for unauthorized users.

  If you have issues with the migration, please raise an issue so that we can find a good solution together.

• Minor breaking change. userContext and root arguments of Executor are moved in Executor.execute method.

• Detect name collisions with incompatible types during schema definition (#117)

• Introduced a type alias Executor.ExceptionHandler for exception handler partial function

v0.5.2

• Added introspection-based schema materializer (#21). This feature has a lot of potential for clint-side tools, testing, mocking,
  creating facade GraphQL servers, etc.

  Here is simple example of how you can use this feature (Using circe in this particular example):

  import io.circe._
  import sangria.marshalling.circe._
  
  val introspectionResults: Json = ??? // coming from other server or file
  val clientSchema: Schema[Unit, Unit] = 
    Schema.buildFromIntrospection(introspectionResults)  

  It takes a results of full introspection query (loaded from the server, file, etc.) and recreates the schema definition with stubs for
  resolve methods. You can customize a lot of aspects of materialization by providing custom MaterializationLogic implementation
  (you can also extend DefaultMaterializationLogic class). This means that you can, for instance, plug in some generic field resolution logic (resolveField method) or
  provide generic logic for custom scalars (coerceScalar* methods). Without these customisations schema only would be able to execute introspection queries.

  By default, default values (for input object fields and arguments) would be ignored because it's just a string as far as introspection API is concerned. However you can enable default value
  support if you know the format of the default values (in many cases it would be JSON). There is even a helper function for this:

  import spray.json._
  import sangria.marshalling.sprayJson._
  
  val clientSchema: Schema[Unit, Unit] = 
    Schema.buildFromIntrospection(introspectionResults,
      MaterializationLogic.withDefaultValues[Unit, JsValue])

  This will inform schema materializer that default values are serialized as JSON and that spray-json should be used to work with them (please note, that
  circe does not have a built-in JSON parsing support, so it can't be used out-of-the-box here. On the other hand, it's pretty easy to add support for particular circe
  parser by defining an implicit instance of InputParser type class).

• SchemaRenderer.renderSchema is now able to render Schema objects and only introspection results (#114). This can be useful if you already
  have schema in memory and don't want to execute an introspection query against the schema in order to render it.

• Query validation rule: Unique variable names (#112)

• Add suggested types to incorrect field message (#111)

• Introspection result now has a parser which deserializes a JSON (or any other format) to a set of case classes. This may simplify client-side tools that work with introspection queries.
  Please use sangria.introspection.IntrospectionParser.parse to parse an introspection query results.

• Introduced InputParser type class in order provide optional support for default value parsing in schema materialization.

• Updated descriptions of a scalar values

• Updated dependencies

• Minor improvements

v0.5.1

• JSON library integration is extracted to separate libraries (#38). Evey integration library will have a separate and independent versioning and release cycle. Following new libraries were introduced:

  • sangria-marshalling-api now includes all of the interfaces that marshalling
    library needs to implement.

  • sangria-marshalling-testkit contains a set of generic test cases that can be used
    to test a concrete marshalling library integration.

  • sangria-spray-json contains an integration with spray-json library.
    From now on, please use following dependency if you would like to use spray-json support:

    libraryDependencies += "org.sangria-graphql" %% "sangria-spray-json" % "0.1.0"

    The package is changed for the sake of consistency. From now on please use following import:

    import sangria.marshalling.sprayJson._

  • sangria-play-json contains an integration with play-json library.
    From now on, please use following dependency if you would like to use play-json support:

    libraryDependencies += "org.sangria-graphql" %% "sangria-play-json" % "0.1.0"

    The package is changed for the sake of consistency. From now on please use following import:

    import sangria.marshalling.playJson._

  • sangria-json4s-native contains an integration with json4s-native library.
    From now on, please use following dependency if you would like to use json4s-native support:

    libraryDependencies += "org.sangria-graphql" %% "sangria-json4s-native" % "0.1.0"

    The package is changed for the sake of consistency. From now on please use following import:

    import sangria.marshalling.json4s.native._

  • sangria-json4s-jackson contains an integration with json4s-jackson library.
    From now on, please use following dependency if you would like to use json4s-jackson support:

    libraryDependencies += "org.sangria-graphql" %% "sangria-json4s-jackson" % "0.1.0"

    The package is changed for the sake of consistency. From now on please use following import:

    import sangria.marshalling.json4s.jackson._

  • sangria-circe contains an integration with circe library.
    From now on, please use following dependency if you would like to use circe support:

    libraryDependencies += "org.sangria-graphql" %% "sangria-circe" % "0.1.0"

    The package is changed for the sake of consistency. From now on please use following import:

    import sangria.marshalling.circe._

• Argonaut scala JSON library is now supported via sangria-argonaut (#59).
  Please use following dependency if you would like to use argonaut support:

  libraryDependencies += "org.sangria-graphql" %% "sangria-argonaut" % "0.1.0"

  And here is an import statement:

  import sangria.marshalling.argonaut._

• Added operationType and operation on ast.Document to easily identify the operation type (#110)

• Added a utility function to convert between different input representations (#108).
  This functionality is available though sangria.marshalling.MarshallingUtil.