Maybe not under the hood, but at the top level it is.
To be clear, I don’t want SQL. I just want GraphQL to do everything Hasura can do so I can develop my apps without lambdas. That’s it. There are a few basic features missing that are huge. However, when we go 9 months without a new version of Dgraph, and the next version does not have one GraphQL new feature (null is a bug fwi)–and we don’t even get updates without begging for them (I know for a fact you have lost users for this reason alone), it is disheartening.
That does sound super interesting!
I think this is just plain wrong. in 99.999% of cases, there are only a few things you want to do with cascade:
- Cascade Delete / Update
- Set Null
- Reject the Query
- Do Nothing (Current Functionality)
- Default Value
If they want to only cascade update where x=tiger in the foreign table, that is so rare and could easily be done with a Trigger (although Dgraph only has a post trigger right now). Granted this is based on mysql, but the actions are based on years of what users need to do with their data. There is a standard for a reason.
This could be easily implemented in GraphQL.
lol, honestly don’t know what an orphan predicate is either.
This is not just OCD. This can have huge unintended effects when searching. The keys can unexpectedly come up, get confused with other nodes etc. This does not even mention the wasted space you’re paying for. Data integrity is very very important.
I believe you. I have learned to get what I need out of it without understanding it exhaustively like I learned with DGraph GraphQL. However, I don’t have time to write my own middleware, and I don’t want to host anything myself to deal with servers etc.
Again, I don’t need all DQL features to get what I need done, just a few basic ones that can get the usefulness from 80% to 95% of most app developers use cases.
So it seems we learned a few things here:
- Dgraph has 2x users: 1) App Developers who want to save time 2) Power Graph DB Users
- There is a huge untapped market for Firebase users, but Hasura is the most similar product—at heart this is a platform, not a database unless you change your product and pricing model (although it seems you don’t realize what you’re selling?)
- There are 3 main missing GraphQL features pretty much everyone agrees on:
- Nested Filters — takes hours to learn and write dql to hack this
- Timestamps — literally can’t be done securely without a custom mutation, making your node unusable
- Cascade Update / Delete - data integrity problems - custom code… hours and hours of your time when sql has this figured out— not everyone is a power graph db user
- –okay 4-- update-after-auth… you have to really get into Dgraph to understand why this should trump the rest–but can add field-level-auth too… i wrote 50 posts about this…
- large schema can get cumbersome-- especially with complex @auth…
- lambdas are time consuming and should only be reserved for complex tasks
- the free tier is too limited
- full text-search is important for both dql and graph db users
- backup is huge / renaming nodes / simple tasks are important— I shouldn’t need to write a custom script for that
- sharding database scaling is important, but not before integrity
- most importantly, the community still does not know anything about the future of the product, its timelines, roadmaps, or even if / when it will at least get regular updates (asking the community questions is only one-sided communication, and is entirely missing the point of why everyone is so frustrated… this post is only going to go so far, and there are things the team CAN talk about… begging for an update once a month is inexcusable
- I am going to keep drilling the communication thing (obviously not from you @MichelDiz, the one person who writes on these forums) until we get a roadmap and timeline… new year is coming, might be a good time to write one… there are things you CAN say, and plans you will keep regardless of other variables…
J