Ok I think I get it now. I tested it and it seems to be working. Thanks!
Do I have to do the same for delete as well?
To delete you need to remove the reference edges. Using the UIDs of the targets to be deleted. If you leave an edge pointing to a UID that has been erased. It will be a dangling “ghost” node.
Ok so for the previous example, to delete a Brand I have to go to all Websites (and whatever holds a Brand) and delete the reference of the Brand too? Is there any good way to do it if we assume that different types can have a Brand?
Yes, and GraphQL has a business logic built-in to do that. If you use DQL, you have to do it by “hand”.
Use GraphQL.
Are there any plans to implement that in DQL as well? Otherwise, there is no point in using DQL at all. My team wanted to migrate to Dgraph because of DQL. Now we see that DQL can’t be used in production.
So, this is a big reason for my team to decided not to go for the Enterprize version and we will stick to our ArangoDB.
We already have a graphQL server that applies extra business logic. We wanted to use Dgraph as a graph database using DQL. Either way. Thanks a lot for all the feedback!
No.
I can’t see why. DQL is a pretty good language. But it doesn’t have “automation” or create a CRUD logic for you. DQL is no different from Cypher, MYSQL, Mongo, REDIS or any other. It is a Database language. I’m not sure what you seek. If you need this kind of thing, you should use GraphQL. DQL is more robust in terms of “bulk searching and dealing with data”. If we try to pivot something else with the lang, this will plaster the language and lose perf. As much things we add(drag), more we lose.
So, what your team thought that DQL was? just to be in the same picture.
Why you can’t use it in prod?
Okay, sure!