IMHO, this “error” should never happen:
{“code”: “ErrorInvalidRequest”, “message”: “Predicate is being moved, please retry later”}
Can’t predicates be moved without downtime to insertions or queries? This kind of internal database operation should be hidden from the user.
Dgraph prevent transactions between predicate moves to maintain consistency of reads and writes for those particular predicates.
It’s important for clients to know to retry later since their request was not completed successfully.
I understand the motivation … other database (most?) do not work this way.
Dgraph is a distributed transactional database. Most other databases aren’t like that.
You should substantiate that claim. I’m looking at this from an enterprise perspective. We handle a lot of very large scale databases here at Orange. Transaction resilience is an expected feature.
Hi Alex, can you explain what are your worries about this?
In priori I don’t believe that info is that much important. But maybe we can add an option to not display it or customize. But please, could you explain exactly where and how it would affect something. Like as security? why?
Cheers.
Having to consistently retry transactions because of “Unable to find log file. Please retry” or “Predicate is being moved, please retry later” makes me question the consistency of the database. It a parallel insert process where idempotency is relative (e.g., data without consistent identifiers), this is very concerning.
Given the inconsistent and unreliable responses, I may have to consider another database solution.
I have seen this issue as well. Because I was testing, I simply deleted all the data and restarted. Though, I wonder how long predicate move should take? My guess is that either there is a bug or a performance bottleneck 'cause it should be pretty fast to move 90MB (that’s the number I observed) data on a high speed 10G network. I remember waiting for at least few minutes if not more before recreating the cluster.