Why is the @id field needed for upserts, what prevents Dgraph from just checking against it’s native uid?
Is there any reason why an @id field shouldn’t be/can’t be auto-populated by Dgraph?
On the second point, it’d be great if there was a directive that indicated that an @id field should be auto-populated by Dgraph with a random ID when the node is created. Just seems like the kind of work the database should be doing…?
Because if you know the id field, it would be an update, not an add - upsert. There is no getPost by @id, and there is no addPost-upsert by ID.
This also has to do with the fact that you can add multiple fields at once, but you can only edit one field at a time. The backend code would have to differentiate between what is a new Post, and what is an update Post. Is there a unique ID or @id? etc…
While this makes sense, I agree that it would be much easier to have one update function that allows you to create, or modify nodes and would automatically match the existing nodes that have an @id or an ID field input.
A lot of the problems Dgraph has not yet solved have already been solved by SQL databases. In this case, we should add an AUTO_INCREMENT @directive.
id: Int! @auto_increment(start: 565)
If you needed to change the start value, just change it in the schema.
Just a thought.
Update: So the start would not work here as every time you update the schema, you would have to think about the start number. However, there could be an internal variable you could set somewhere in dgraph, a globals section maybe, that stores that number to change it.
well in a way it would work if the process was smart about it like MySQL handles it. In the schema in MySQL for an AI field you can define a start. But if you define a start that is below the some existing data then the incrementing value stored in the database actually gets set to the minimum value of the data. So while it would take a bit more logic, it still would be possible to have it in the schema and is where I would expect it to be defined. That would also make it easy to say, ok let’s skip the next X and start from here on out at Y with a schema deploy. So the value in the schema would not be the actual next value, but instead it would be the minimum value to use as next and the minimum of the actual data +1 would be next.
For an even more advanced mode, it is possible in MySQL databases to do a strange logic to count evens, or odds, and I think even more advanced options. At one time I had two MySQL databases on separate servers that a user could write to either one and read from either one and they would sync whenever they were capable of doing so. Sort of like an offline database capability. But that is another entire discussion