Deleting node with required inverse edges

[jdgamble555 (Jonathan Gamble)]

@anand Agreed it is not the responsibility of the database for everything. However, if the user does not have the tools to properly model and USE the database efficiently to keep the database consistent, that is on the database developers!

Please read my two articles, as I have solved the problem for you if you guys listen:

Feature Request: Cascade Delete & Deep Mutations By Reference Directive

Experience Report for Feature Request Update: 7/1/21 - to comply with Feature Request Template: What you wanted to do 1.) Update nested nodes from the parent Update Mutation. 2.) Delete nested nodes from the parent Delete Mutation 3.) Choose which nodes allow this Cascade Delete and Cascade Update, as not all parent / children relationships should have this ability What you actually did 1.) This can only be done by creating a new update mutation for EVERY SINGLE child individually. If I …

Hacking the @cascade delete and phantom node problem

So, yes, dgraph can fix this problem by implementing my feature suggestion (I also talk about the basic hack for now in this link): However, there is a bigger issue here. I think we don’t always think about things the way they are. Dgraph handles arrays as shared arrays unlike a noSQL database in example. Example Type Item { id: ID! name: String! @id ... } Type Cart { items: [Item] ... } If we have something like: items: [bread, butter, eggs...] those items may be shared by …

---

This is 100% the problem!

@amaster507

Dgraph is only going to focus on their service as a database and not their service as a complete backend API solution

You guys made a great product, then you put GraphQLl on it. This is awesome! However, that extra layer has no security except basic JWT validation, and the Dgraph team seems to just ignore the MOST IMPORTANT user needs. We are stuck with Dgraph’s GraphQL layer, which is VERY VERY LIMITED, and more importantly, with NO HOPE of fixing the problems.

Start thinking about what MOST users will need

If all of your developers are database developers and not frontend developers, you may not understand this list. However, what you are selling is NOT a DbaaS, but a Database platform! The platform needs to come first, and it seems like it is at the bottom of the list. Yes, we realize there are money issues with getting things done, but PRIORITIZE your paying cloud users, or lose them!

Here is where we are:

• Basic backend security
  • You have to create a lambda mutation for EVERY mutation
  • post-hooks are worthless because you have no access to original data
  • There are no pre-hooks, as promised, so you have to create that extra-coded custom mutation every time
• Foreign Keys
  • As I spoke about in my first article, in some cases, it is IMPOSSIBLE to keep the database consistent without using a lambda mutation, again, only a custom lambda mutation.
  • This is NOT the job of the user, but the job of the database!
• User / Roles
  • While I don’t think having a user / roles system is a must for this Dgraph GraphQL, allowing GraphQL to save a role in the database, and check the user’s role is a must
  • Imagine a front-end developer having to change the JWT in order to change any RBAC information every time. This is insane!
• Nested Filters / Facets
  • I believe you guys are aware of the problems not having nested filters. Was supposed to be fixed in 21.07, lol. Nhost.io is a good example of a DbaaS (postgres) that has GraphQL nested filters built in. I would argue that facets should come last, but still important.

How to fix this GraphQL (in this order)

Obviously all bugs come first, then documentation, then…

1. after-update-bug
2. @reference directive
3. nested filters
4. database role validation

• pre-hooks
• facets

I would state that the first 4 are simply a must. Put all cloud and data studio upgrades to the side.

To get back to this post, imagine a MYSQL database having to write a stored procedure for every sql foreign key query transaction. Imagine noSQL having to write a custom function or lambda for every add / update / set for security.

People go away from mysql because of speed and scaling. People found noSQL. People go away from noSQL because of a lack of relations and writing custom functions to fix it. People found GraphDB. People stick with GraphDB because it quick, scales, secure, solves relationship problems clearly and automatically.

Dgraph is almost there, but the Dgraph team keeps arguing about the usefulness of these things, focusing on everything but the front-end user. Start looking at their needs! They are your users!

We have drawn you a map! --the regular users here with their real struggles

Then again, maybe you guys are not ignoring GraphQL problems, but all we see is no communication at all on what you are working on, or arguments about what you believe is important… neither is promising.

I would not be taking 30 minutes of my time to write this post if I did not believe in this product. Please understand the real needs of your real users.

J