I am attempting to move my src code over from FQL to Graph.
I am doing this for the added benefit of having a .gql file that can auto-build the database.
Below are a few things I would like to learn how to do, some may not be possible, but asking in the chance that they are. I have done ample research/testing before posting to make sure I am not wasting anyone’s time
1: Define an index for a property within a collection.
I have tried several keywords and syntaxes, and the only one that did not error out when importing the gql file was this one below… However, it did nothing and did not generate any indexes. type Foo @model@key(name: “index_name”, fields: [“field_name”])
2: Include FQL logic in Graph Schema.
I doubt this would be possible but would be fantastic if it was… It would mean I don’t have to write additional steps for people to follow when cloning my project.
For example, with function as an additional field in resolver: countFoo: Int! @resolver(name: “countFoo”, function: “Query(Lambda(”_“, Count(Documents(Collection(“Foo”)))))”)
3: Unique field for embedded types.
I marked a field within an embedded type as unique. I was assuming the result of having an index as followed ‘data.foo.embeded_type.embedded_field’. Guessing not possible? I could mark the entire embedded object as unique, but that would break for my use-case.
Thank you in advance. Any help would be appreciated
I have tried several keywords and syntaxes, and the only one that did not error out when importing the gql file was this one below… However, it did nothing and did not generate any indexes. type Foo @model@key(name: “index_name”, fields: [“field_name”])
The documentation also describes how to cause indexes to be created with appropriate terms definitions.
Include FQL logic in Graph Schema
That is not possible. FQL is not part of the GraphQL specification.
You can use resolvers to apply an FQL UDF to specific fields in a type. See @resolver.
Unique field for embedded types.
As far as I know, that should work. You’d have to share your schema and some sample documents for us to verify whether there’s a problem with those or how the GraphQL API operates.
The documentation also describes how to cause indexes to be created with appropriate terms definitions.
Yup, the first part was a wild stab at maybe hitting something undocumented. It seemed to be a shared syntax and supported feature for other/similar platforms.
Unfortunately, the resolver is only for queries, so I wouldn’t be able to do something like this.
type Foo
{
thing: String @resolver(name: "index_thing")
}
Or am I misunderstanding something that you’re explaining? I would have thought this be a feature, considering indexes are heavily depended on.
Include FQL logic in Graph Schema
Ok cheers. Its a shame, I would assume that whilst yes its not a globally supported gql schema syntax, it would still be possible as fauna is just processing a file, and interpreting. Much like the resolver directive, and adding in an entry into the functions list…
Unique field for embedded types.
Here is an example. If I upload the file, only foo.name will have an index created.
This one is no biggy, I was just trying to encapsulate the credentials details on my project. But there is no reason why I cant have the embedded content at a top level.
type Foo
{
name: String @unique
child: FooChild
}
type FooChild @embedded
{
sub: String @unique
}
Or am I misunderstanding something that you’re explaining? I would have thought this be a feature, considering indexes are heavily depended on.
A resolver is called when you act on a type. You might need a different resolvers for queries and mutations, so defining the resolver on a type’s field doesn’t make as much sense.
it would still be possible as fauna is just processing a file, and interpreting.
Fauna is processing a GraphQL query, so we have to adhere to the GraphQL specification. Otherwise, it’s not GraphQL.
Here is an example. If I upload the file, only foo.name will have an index created.
Apparently, creating indexes for embedded types is something that just hasn’t been implemented yet. There’s no fundamental limitation, since Fauna indexes can specify unique constraints for any field, at any depth, within a document.
Thanks for reporting the problem! I’ve filed GQL-365 to get that addressed.
And I decided to just use FQL to fill in the blanks that I cant with a GQL Schema.
Not a bad comprimize, as I would only need to use the FQL for an initalizer to generate indexes and populate resolver logic.
I really do love what Fauna is doing. Havent come accross anything yet that comes close to competing in terms of support, performance, and price.
