Yes. If you have a huge Tablet indexation for the Type. This could potentially increase latency. There are ways to mitigate this.
When you talk about the query root, you are not traversing anything. The query root param is applied only for the Root target nothing more. Traversing is done through nesteding.
But depending on the relationship you will need to query for all to all. Many to many.
Stay with me, it works. But not the way you think it does.
It is expected behavior.
This is the way.
I’m not advising, I’m just giving examples of how it works. In some parts I advised, but that’s just my opinion. It’s preferable to have predictable queries than use recurse. But it is your call if you feel okay and understand how the query works.
Yes. But you can have techniques like naming. For example “product.name”, “user.name”, “object.name”. With this you can isolate this side effect in a big dataset. You can also create a structure on top of your data and use edges to expand your data. But this is a bit complicated.
Not sure, can you share an example of what you seek? I get it, but not sure about the form of it.
1 and 2 are fine. Something to the docs team to take a look.
The 3 it is off the table. This is how Dgraph is designed.
And about the 4, that’s not an issue at all. I think I explained why this happens.
The root query will never be applied to the query body or nested blocks. It is used to find the target. If you wanna do filters with recurse you have to do in the query body itself.