TLDR; I feel like Dgraphs biggest need is Developer eXperience. DX is the only thing stopping me from using it on more projects, or pushing my clients and partner devShops to use it more.
To be clear, you’re talking about Nested Filters(probably the most requested GraphQL Feature).
…
And this is my suggestion, the @reference directive. This could be accomplished now by using a post-hook lambda, but you would have to write it. This is definitely a huge missing feature, but do-able now.
Yup, Nested Filters. I realize that you can do it now writing a custom Lambda, but in many DGraph and modern competitors you don’t have to.
Well, you can break the schema into separate files. It is very simple. The Schema API is very straightforward, you can add OR delete. Which means you can add any piece of the schema at any moment that it won’t break or undo anything. It will be a problem tho if you set a different thing to the same predicate several times. This can trigger the indexing process or something.
Can you explain what is your issue with this in detail?
Sure! To start with let me address your points:
The Schema API is very straightforward, you can add OR delete.
Yes, but why? Building a basic file list on the side, an editor on the right, and saving in the UI is not a large task. Particularly if it adds additional insights, checks, and guidance. Most competitors have one. It makes it a lot easier for me to setup team coordination and training to have a central UI representing our DB, backend, and it’s metadata.
I feel like these kinds of small things are part of the reason DGraph may be struggling. Your response comes across as a little defensive, which makes sense. You’ve built a neat product and want people to like it and use it, but it isn’t polished and it isn’t intuitive, and those small differences add up in the long run by pushing training costs back on to me, your customer.
Is the DGraph team hungry to build something revolutionary? You’re on the cusp of having my dream backend. I don’t know you, but I don’t see that hunger here on the forums. I see responses indicating you feel like you should have already one and everyone should recognize it.
“Bulk updates, bulk deletes, renaming columns, moving/copying data from one column to another.”
Can you tell what are the solutions in other DBs related to this? this looks obvious manual work to me. Humm, maybe you want something like Ratel to do things like renaming?
Does anyone on your team have significant SQL experience?
I don’t care where it happens, even it if was just an API call, and it’s just an example of some of the basics I’ve had to fight. Here are some examples of things that are 1 minute tasks in Postgres, but at least an hour or two, if not more in dgraph:
Renaming a column in SQL looks like this:
update table product rename column product_price to price;
This will change the name of the column, but keep the data type and all data on the row connected to the row still, no data loss, no orphaned predicates. I realize it’s not as easy here since you’re maintaining each field via predicates in a map instead of indexing rows by byte length.
There are two hard things in programming: Cache invalidation, naming things, off by one errors.
Jokes aside, naming things is hard, anyone not renaming their fields occasionally either has a massive database, or is a foolish.
Bulk copy
Update TableB set column1=(select Val from TableB where ....) and set column2=(select Val from TableB where ...)
In some cases I might need to do a window to prepare the data
select data from (select a, b, c from TableC C join TableD D on C.id=D.id group by ....)
update TableA set column1 = data.a where data.b = TableA.g
Now that I understand DQL better, this mostly works until I have to get into anything nested.
A live example that came up yesterday, and that I’m still fighting. In my product we have tagging. So my schema looks like this:
type Tag { id: ID, taggedItems: [Item] @hasInverse(field: tags) }
type Item {id: ID, tags: [Tag] @hasInverse(field:taggedItems) }
Except some how, the @hasInverse isn’t working, so I only have one collection populated. I’m trying to copy from Item into Tag, and because of a bug in DQL nested predicate variables are not flattened and it doesn’t work (this is talked about elsewhere on the forum).
And once that’s done I still have to figure out exactly which pattern of adding data will trigger the @hasInverse correctly and which one will not.
Bulk Deletes
Now that I know some DQL better, this is mostly okay. Getting an error in Ratel of “t” and just that then having to dig into the network logs and the docs to figure out the status codes is annoying, but tolerable enough, it would be a lot nicer if it just said “Not logged in”. Non-200 error codes can send status messages that could be displayed, it isn’t complicated either.
My biggest issue with bulk deletes is even if it does work, I’m constantly hitting the 1,000,000 count meaning I not only have to figure out the right way to modify the data, I have to architect a paging solution. Yes, I need to learn more about DGraph and get better at DQL, I’m working on that, but my goal is a simple copy of data that would take me 1 minute in SQL. I don’t make any money wrestling DGraph data, I lose money.
Removing a column
In SQL:
alter table TableA drop column old_column on cascade delete
And just like that I’ve removed a column, all of it’s data (no orphaned predicates), and removed any child tables that were reliant on me.
Computed Columns
In Postgres:
`alter table TableA add column name text generated always as (CONCAT(first_name, ’ ',last_name)) stored;
And just like that I have a computed column that recalculates itself every time the first_name or last_name are updated
Summary
DGraph is 70% of the way to being my dream backend. I specialize in rapid full-stack development, but I also try to account for scalability. I would love to have backend that I can quickly throw a prototype together for a client for, and then not have to re-work it after 2 years as they scale. AWS lambdas can deliver scale, but not the flexibility of a graph DB, and it’s not fast. SQL is fast and clean, but doesn’t scale without significant continued effort and investment, and even re-planning and structuring your data for partitions.
DGraph could do both/all of that, you just need polish honestly. Too many small barriers that add up so that I can’t convince one of my clients to train their junior on it or to take the plunge.
My backend selection process:
Does the project need scale? If no, then use Hasura because I can build a lot faster on it.
If yes, continue:
Does the project also have a lot of relationships like a recommendation engine, a feed/timeline, or something like that? Consider DGraph
Does the product need a lot of subscriptions (live chat, etc)? Consider Hasura since they’ve proven their subscription effectiveness (See Hasura scale to 1 million active GraphQL subscriptions/live queries)