Parameterized Cascade

Dev
21

This feature will only be GraphQL± , not GraphQL.

22

GraphQL already has a cascade feature, so it can go into GraphQL as well.

1 Like
23

Ok. The initial scope was to just do GraphQL±. I will note this to scope out the effort needed.
cc @pawan

24

Thank you @mrjn, @paras, and @pawan!

1 Like
25

This should be an easy one to support and we will prioritize this.

1 Like
26

@gja, I understand this does not support the graphql endpoint, but now that we can run DQL (Graphql±) on Slash, can this get pulled in?

27

@Paras is this a small enough PR that we should consider merge this into Slash now?

1 Like
28

Hi @amaster507, Parameterized cascade is now avaliable in graphql also. Currently it’s in master only.
Here is PR link Feat(GraphQL): This PR adds parameterised cascade in graphql. by JatinDevDG · Pull Request #6251 · dgraph-io/dgraph · GitHub

4 Likes
31

Hi there,
Are parameterized cascades working in DQL? I can’t find any reference to them in the documentation here: https://dgraph.io/docs/query-language/cascade-directive/

Thank you!

32

You’ll find it in the GraphQL->Queries section: https://dgraph.io/docs/graphql/queries/cascade/#parameterized-cascade.

33

GraphQL is different from DQL. DQL errors out if I’m using the same format of @cascade(fields: ["name"])

I tried guessing by using the suggested format above @cascade("name") and the cascade just lost all effects as opposed to ensure the name field.

34

Yeah. Can you check if this thread helps?

35

Thank you for the thread link. Unfortunately this does not work as expected. Cascading the filtered field only removes the field in which it was filtered on. But does not remove elements from the top level query. Happy to create a reproduction if need be.

Thanks

36

Hi @marwan-at-work

I’ve informed our Documentation team to add related docs for parametrized cascade in the related DQL section.

Regarding your particular issue, as you said, can you provide a reproduction case so we can look into it. I think it’s just a matter of query review. Talking in general if you want to remove elements from your top level query you can add @cascade at the root func level. Maybe with an example it will be easier

Best,

37

Hi Omar,
Yes, bellow is a full repro that shows how parameterized cascade is not working as expected.

Notice, how I have a top level @cascade while filtering by a car that doesn’t exist yet the top level still shows up when printing the json.

package main

import (
	"context"
	"fmt"

	"github.com/dgraph-io/dgo/v200"
	"github.com/dgraph-io/dgo/v200/protos/api"
	"google.golang.org/grpc"
)

var ctx = context.Background()

func main() {
	c := newClient("localhost:9080")
	err := c.Alter(ctx, &api.Operation{
		Schema: `
			email: string @index(exact) .
			hairColor: string .
			carName: string .
			cars: [uid] @reverse .

			type User {
				email
				hairColor
				cars
			}

			type Car {
				carName
			}
		`,
	})
	must(err)
	createUser(c)

	resp, err := c.NewReadOnlyTxn().Query(ctx, `query {
		users(func: has(email)) @cascade(carName) {
			uid
			email
			hairColor
			cars @filter(eq(carName, "fakeCar")) {
				uid
				carName
			}
		}
	}`)
	must(err)
	fmt.Printf("%s\n", resp.Json)
}

func createUser(c *dgo.Dgraph) {
	_, err := c.NewTxn().Mutate(ctx, &api.Mutation{
		SetNquads: []byte(`
			_:u <email> "me@gmail.com" .
			_:c <carName> "volvo" .
			_:c2 <carName> "toyota" .
			_:u <cars> _:c .
			_:u <cars> _:c2 .
		`),
		CommitNow: true,
	})
	must(err)
}

func newClient(url string) *dgo.Dgraph {
	d, err := grpc.Dial(url, grpc.WithInsecure())
	must(err)

	return dgo.NewDgraphClient(
		api.NewDgraphClient(d),
	)
}

func must(err error) {
	if err != nil {
		panic(err)
	}
}

Playing around some more, I think I’m getting the right results if I use the actually cascade not on the filtered field, but on the field the filter is being applied to. In other words @cascade(cars) works as opposed to @cascade(carName)

Thanks

38

Hi @marwan-at-work,

Sorry for the delay, let me look into what you provided.

Best,

39

I think you are facing the same problem as I have already answered in this thread.

The rule with @cascade(predicate) is that the predicate needs to be in the query at the same level @cascade is. So, @cascade(carName) at a level where carName isn’t a predicate won’t have any effect, while @cascade(cars) works because the predicate cars exists at that level in the query.

Sorry for the confusion you faced. We have noted that we need to update our docs about the finer details of how @cascade works.

Thanks

1 Like