I'm trying to pass an options hash as an argument in my GraphQL mutation. I want to update multiple fields for an object, based on the fields passed into the mutation.
It's going to look like this: updateStatus(statusId, options)
I'm not sure how to specify a hash/object in the typeDefs for graphql-yoga server which also uses apollo server.
I've tried everywhere and no resources have shown up for what should be an extremely common operation.
You just have to define a new type to represent the options argument, for example:
input OptionsType {
field1: Int!
field2: String
}
And then use it in your mutation:
type Mutation {
updateStatus(statusId: String!, options: OptionsType): ReturnType
}
I used the "GraphQL schema language" in the examples, but it should be easy to use the same idea in another language.
The accepted solution only works for Hashes with predefined fixed keys.
(field1 and field2 on the accepted example).
On my scenario, I was requiring a Hash with dynamic/flexible keys. If someone is interested in learning how I accomplished that, I managed to do that by declaring a new Scalar Type which reflects the Ruby language Hash type, from Ruby to GraphQL.
Setup
app/graphql/types/hash_object.rb
class Types::HashObject < Types::BaseScalar
description 'A Hash Object'
def self.coerce_input(input_value, _context)
input_value.to_h
rescue StandardError
raise GraphQL::CoercionError, "#{input_value.inspect} is not a valid Hash"
end
def self.coerce_result(ruby_value, _context)
ruby_value.to_h
end
end
Usage
argument :my_argument_name, Types::HashObject
GraphQL-Ruby has the JSON type, which would help here.
https://github.com/rmosolgo/graphql-ruby/blob/master/lib/graphql/types/json.rb
# Use it for fields or arguments as follows:
# field :template_parameters, GraphQL::Types::JSON, null: false
# argument :template_parameters, GraphQL::Types::JSON, null: false
Related
I am new to Drools, we are trying to create basic validation rules like a NULL check, etc. using the Drools n Scala framework.
I have a source file which has 200 attributes, need to apply NULL-check rule on all these attributes,
is there any easy way to do this? or do I need to create 200 rules for each attribute?
Thanks in advance.
Assuming you have a POJO ("plain old java object", getters/setters and some private variables to hold values) or modern java Records (effectively the same thing), then the answer is no: you need separate rules. For this scenario, the only way to check that field "name" is null is to actually assert against that field like this:
rule "example - name is null"
when
ExampleObject( name == null )
then
System.out.println("Name is null.");
end
However there exist other data structures -- for example, Map and its sibling types -- where you can reference the fields by name. In this case you could theoretically iterate through all of the field names and find the one whose value is empty.
So, for example, Map has a keySet() method which returns a set of fields -- you could iterate through this keyset and for each key check that there is a non-null value present in the map.
rule "example with map"
when
$map: Map()
$keys: Set() from $map.keySet()
$key: String() from $keys
String( this == null ) from $map.get($key)
// or this might work, not sure if the "this" keyword allows this syntax:
// Map( this[$key] == null ) from $map
then
System.out.println($key + " is missing/null");
end
This would require converting your Java object into a Map before passing into the rules.
However I DO NOT RECOMMEND this approach. Maps are extremely un-performant in rules because of how they serialize/deserialize. You will use a ton of unnecessary heap when firing them. If you look at how a HashMap serializes, for example, by peeking at its source code you'll see that it actually contains a bunch of "child" data structures like entryset and keyset and things like that. When using "new", those child structures are only initialized if and when you need them; but when serializing/deserializing, they're created immediately even if you don't need them.
Another solution would be to use Java reflection to get the list of declared field names, and then iterate through those names using reflection to get the value out for that field. In your place I'd do this in Java (reflection is problematic enough without trying to do it in Drools) and then if necessary invoke such a utility function from Drools.
Following on form this excellent set of answers on how to define union types in Scala. I've been using the Miles Sabin definition of Union types, but one questions remains.
How do you work with these if the type isn't know until Runtime? For example:
trait inv[-A] {}
type Or[A,B] = {
type check[X] = (inv[A] with inv[B]) <:< inv[X]
}
case class Foo[A : (Int Or String)#check](a: A)
Foo(1) // Foo[Int] = Foo(1)
Foo("hi") // Foo[String] = Foo(hi)
Foo(2.0) // Error!
This example works since the parameter A is know at compile time, and calling Foo(1) is really calling Foo[Int](1). However, what do you do if parameter A isn't known until runtime? Maybe you're paring a file that contains the data for Foo's, in which case the type parameter of Foo isn't know until you read the data. There's no easy way to set parameter A in this case.
The best solutions I've been able to come up with are:
Pattern Match on the data you've read and then create different Foo's based that type. In my case this isn't feasible because my case-class actually contains dozens of union types, so there'd be hundreds of combinations of types to pattern match.
Cast the type you've just read to be (String or Int), so you have a single type to pass around, that passes the Type Class constraint when you create Foo with it. Then return Foo[_] instead. This puts the onus back on the Foo user to work out the type of each field (since they'll appear to be type Any), but at least it defers having to know the type until the field is actually used, in which case a pattern match seems more tractable.
The second solution looks like this:
def parseLine: Any // Parses data point, but can be either a String or
// Int, so returns Any.
def mkFoo: Foo[_] = {
val a = parseLine.asInstanceOf[Int with String]
Foo(a) // Passes type constraint now
}
In practice I've ended up using the second solution, but I'm wondering if there's something better I can do?
Another way to state the problem is: What does it mean to return a Union Type? Functions can only return a single type, and the trickery we use with Miles Sabin union types is only useful for the types you pass in, not for the types you return.
PS. For context, why this is a problem in my case is that I'm generating a set of case-classes from a Json schema file. Json naturally supports union types, so I would like to make my case classes reflect that too. This works great in one direction: users creating case-classes to be serialized out to Json. But gets sticky in the other direction: user's parsing Json files to have a set of populated case classes returned to them.
The "standard" Scala solution to this problem is to use an ordinary discriminated-union type (ie, to forego true union types altogether):
sealed trait Foo
case class IntFoo(x: Int) extends Foo
case class StringFoo(x: String) extends Foo
This reflects the fact that, as you observe, the particular type of the member is a runtime value; the JVM type-tag of the Foo instance provides this runtime value.
Miles Sabin's implementation of union types is very clever, but I'm not sure if it provides any practical benefit, because it only restricts the type of thing that can go into a Foo, but provides the user of a Foo with no computable version of that restriction, in the way a match provides you with a computable version of the sealed trait. In general, for a restriction to be useful, it needs two sides: a check that only the right things are put in, and an extractor (aka an eliminator) that allows the same right things to come out the other end.
Perhaps if you gave some explanation of why you're looking for a purer union type it would illuminate whether regular discriminated unions are sufficient or if you really need something more.
There's a reason every JSON parser for Scala requires well defined types into which the JSON will be converted, even if some fields have to be dropped: you cannot work with something you don't know the type of.
To given an example, say you have a, and maybe a is a String, maybe it's an Int, but you don't know what it is. Why computation could you possibly make with a, not knowing its type? Why would your code compute the sum of all a's, for instance, if you didn't know in advance it was a number?
Generally, the answer to that is to perform user-provided data manipulation at runtime over data with unknown characteristics, as the user itself sees that it's a number and decides they want to know what the sum of that field is. Fine, but you are going the wrong way about it if so.
There is a well defined way to represent JSON data in Scala (and, for that matter, any data that has the same characteristics as JSON. Which is using a hierarchy of classes. A json value may be a json object, array or one of a number of primitives. A json object contains a list of key/value pairs, whose keys are json strings and values are json values. And so on. This is easy to represent, and there are many library doing so already. In fact, there are so many that there's a project called Json4s which presents a unified API which can be used and is implemented by many of the aforementioned libraries.
Things like the records which Miles Sabin's Shapeless library provide are intended to be used when the input doesn't have a well defined schema, but the program knows what it needs from that input. And, yes, the program might know what to do with a if it is an Int or a String, but not every possible value.
The next Scala 3 (mid 2020) based on Dotty will implement the proposal for Union Type from last Sept. 2018
You see it in "a tour of Scala 3" (June 2019)
Union Types Provide ad-hoc combinations of types
Subsetting = Subtyping
No boxing overhead
case class UserName(name: String)
case class Password(hash: Hash)
def help(id: UserName | Password) = {
val user = id match {
case UserName(name) => lookupName(name)
case Password(hash) => lookupPassword(hash)
}
...
}
Union Types Work also with singleton types
Great for JS interop
type Command = "Click" | "Drag" | "KeyPressed"
def handleEvent(kind: Command) = kind match {
case "Click" => MouseClick()
case "Drag" => MoveTo()
case "KeyPressed" => KeyPressed()
}
The 1.0 implementation looks like this.
defmodule Chat do
use GenServer
#derive [Access, Collectable]
defstruct [api: APIClient, chat_id: nil, clients: %{}]
def start_link(params), do: GenServer.start_link(__MODULE__, params)
def init(params) do
state = Enum.into(params, %__MODULE__{})
{:ok, state}
end
...
end
First problem is that Access has been deprecated, does that mean I have to change the dot notation when accessing state fields?
Second problem is that if I don't remove the #derive Collectable I get this error Collectable.Any is not available, cannot derive Collectable ....
Here params is a keyword list, I supose I could convert the keyword list to a Map with state = Map.merge(%__MODULE__{}, Enum.into(params, %{})) but feels terribly clumsy.
I'm not sure about the particular Collectable issue, but there's a much better solution to your particular problem - constructing a struct from a list of key-value pairs.
You can use Kernel.struct/2 for that. It won't only construct the struct for you, but also validate the keys, and use only those that really are in the struct. Since 1.2 there's Kernel.struct!/2 that will raise in case any of the provided keys is invalid.
I have seen PowerShell function parameters defined using the syntax param([parametertype[]]$Parameter) as well as param([parametertype]$Parameter).
Personally, I have always used the latter with (as far as I can tell) no problems. Can anyone explain what (if any) is the difference and why both are allowed and work?
[parametertype[]]$Parameter is a parametertype array of $Parameter
[parametertype]$Parameter is a $Parameter of parametertype
i.e.
> [string]$param_s = "parameter"
> [string[]]$param_a = "parameter", "param2", "param3"
> $param_s[1]
a
> $param_a[1]
param2
Note how param_s is a plain string and accesses the second position in the string when accessing index [1] compared to what's returned by param_a[1]
When used by the param keyword in a function / cmdlet definition, it just ensures the function will be passed correct data type
in powershell you don't have to define what parameter you are using but you can.
sometimes it can be handy if you want to define a parameter as [mandatory] for example.
in your example you defind an array type param[] and single type.
you can read more about Defining Parameters.
I am new to Perl and reading about references.
I can not understand how doe one know if the variable he work on is a reference.
For instance if I understand correctly, this:
$b = $a could be assigning scalars or references. How do we know which is it?
In C or C++ we would know via the function signature (*a or &a of **a). But in Perl there is no signature of parameters.
So how do we know in code what is a reference and what is not? Or if it is a reference to scalar or array or hash or another reference?
Perl has a ref that you can use for that:
Returns a non-empty string if EXPR is a reference, the empty string otherwise. [...]
The string returned (if non-empty) will tell you the type of object the reference references.
You're asking the wrong question.
While there is a function called ref and another called reftype, these are not functions you should ever need to use.
It's bad to check the type of variables, because there's no way to effectively know without actually using it as intended due to overloading and magic.
For example, say you designed a function that accepts a reference or a string. That would be a bad design because an object that overloads stringification is both.
A good interface would use context to differentiate the arguments. For example, it could differentiate based on the number of arguments,
foo($point_obj)
-vs-
foo(x => $x, y => $y)
based on the value of other arguments,
foo(fh => $fh)
-vs-
foo(str => $file_contents)
or based on the choice of function called
foo_from_fh($fh)
-vs-
foo($file_contents)
So the answer is: You know it's a reference because your documentation instructs the caller of your function to pass a reference. If you got passed something other than a reference and it's used as a reference, the caller will get a strict error for their error.
The ref function is what you're looking for. Documentation is available at http://perldoc.perl.org/functions/ref.html
ref EXPR
Returns a non-empty string if EXPR is a reference, the empty string otherwise. If EXPR is
not specified, $_ will be used. The value returned depends on the type of thing the
reference is a reference to...