ActiveQL Documentation

Operation Configuration

OperationConfig

Option	Type	Default	Description
input	`string` \| `string[]` \| `{[name:string]:true \| OperationInputConfig}`		Definition of the input type for the Mutation
result	`string` \| `string[]` \| `TypeConfig`		Definition of the result type for the Mutation
description	`string`		Description of the Mutation in the schema
resultTypeName	`string`	OperationName`Result`	name of the result type in the schema
returnTypeName	`string`	OperationName`Return`	name of the return type in the schema this includes the result, the ValidationViolation and the _Dispositions
`onContextCreate`	`(ctx:OperationContext) => void`		callback at context creation, giving the opportunity to add properties to the context
`dispostions`	`OperationFn<void>`	based on input definition	custom implementation to determine the attribute dispositions
`beforeValidation`	`OperationCallback<boolean>`		callback before any input is validated, giving the opportunity to manipulate the input
`validation`	`ConfigSource<void>`	based on input definition	validation of all input attributes
`beforeSave`	`OperationCallback<boolean>`		callback before any input is saved to the DataStore after successful validation, giving the opportunity to manipulate the input
`save`	`boolean` \| `OperationFn<boolean>`	based on input definition	saving input as entity items to the DataStore
`afterSave`	`OperationCallback<boolean>`		callback after any input is saved to the DataStore
`buildResult`	`OperationFn<boolean>`	based on result definition	building the data type for the mutation's result
`afterBuildResult`	`OperationCallback<void>`		callback after the result was built; giving the opportunity to manipulate the result

Operation Input

While the input for an entity mutation is a plain object, the input of an operation can nested and as complex as your domain requires. For details please refer to Input Configuration

Config	Description
`EntityName`	any string value is resolved as `{ entity: entityName, attributes: true}` meaning the input is exact the input of the referenced entity
`{ EntityName: true}`	any of this items is resolved as `{ entity: entityName, attributes: true}` meaning the input is exact the input of the referenced entity
Map of `OperationInputConfig`	You can configure a complex, dynamically evaluated and validated input types

Entity name

The most simple input (and result) definition would be referencing an entity. This operation would behave very similar to the createCar mutation. It takes a car input, saves it and returns it as result.

entity:
  Car:
    attributes:
      brand: String!
      licence: String!
operation:
  RentCar:
    input: Car
    result: Car

In this example the GraphQL schema mutation type would look like this:

'RentCar(car: RentCarInputCar): RentCarReturn'

The input type RentCarInputCar looks very much like the input type for the update mutation of the Car entity.

input RentCarInputCar {
  id: ID
  brand: String
  licence: String
}

If you have more than one you can use the entity name as key of the input configuration.

entity:
  Car:
    attributes:
      brand: String!
      licence: String!
operation:
  RentCar:
    input: 
      Car: 
        entity: Car
    result: Car

The GraphQL schema mutation type would now look like this:

'RentCar(car: RentCarInputCar): RentCarReturn'

Operation Result

{ result: string | string[] | TypeConfig }

Config value	Description
`string`	entity
`string[]`	list of entities
`TypeConfig`	a custom type configuration

Besides the inputDispositions and validationViolations an operation should return the result of the business logic that is executed after any input was successfully validated.

The result configuration simply declares the type of that return value. It can either be an entity, a scalar or any (non-input) type from the DomainGraph.

Obviously the business logic (mainly the buildResult implementation) must set a value in the operations result that matches this definition.

Overview Input configuration