v0.9 is introducing support for transactions, which is a MAJOR change throughout the codebase, and significantly affects how users interact with Dgraph.
HTTP /query endpoint is going away
All the queries and mutations would be done via a transaction API, which is going to be coordinated via Dgraph clients. As such, we have significantly simplified the clients, so that we can easily replicate the functionality and maintain various clients for different languages.
Update (1/11) - We have heard your feedback and brought back the http /query endpoint. Infact we have full support for transactions using http.
We will have the following endpoints
- POST
/queryto do queries. - POST
/mutateto do mutations. Mutation block doesn’t require themutationkeyword anymore since we have a separate endpoint for it. - POST
/committo commit a transaction. - PUT
/abortto abort a transaction. - PUT
/alterto drop a predicate, drop all data and do schema mutations.
Queries and mutations are separate
Queries would no longer allow a mutation { ... } block. All mutations would be done via a Mutate Grpc endpoint, called via the client or the /mutate http handler.
Mutations would accept set / delete JSON, or set / delete list of NQuads, and various other operations.
/mutate http handler would only accept raw mutations but without the mutation keyword.
E.g.
{
set {
<name> <is> <something> .
<hometown> <is> <san/francisco> .
}
delete {
<name> <is> <something-else> .
}
}
No more upsert and mutation variables
With the availability of transactions, a user can query for data, and then write their mods back atomically. Thus, upsert and mutation variables can be done via client-side logic, instead of baking this limiting functionality in the server.
JSON over protobuf messages
JSON is taking a prominent role. All responses would now be in JSON format, wrapped in a protobuf along with other information, useful to the client. We would no longer encode the subgraph in proto messages.
We’re getting rid of the dgraph tag in Go structs, which used to help unmarshal these proto messages. Now Dgraph’s reponse can just be unmarshaled using standard JSON.
Schema mutations
Schema mutations would be fed via a new Alter GRPC endpoint. It would take a schema block string, and execute it. All the parsing would be done at the server side. This endpoint would also be used to drop a certain predicate or to drop the entire DB.
Breaking: Given this, sending a <*> <pred> <*> . delete mutation to delete a predicate wouldn’t be allowed via Mutate endpoint.
Live Loader [under consideration]
Dgraph live loader should no longer store the external ids in Dgraph. That seems like a very specific solution for a broader problem. So, a user could use the client directly to load data and achieve custom functionality.
Dgraph Flag Changes
A change went in today to automatically allocate Raft ids to Dgraph servers. A user can optionally still specify an ID, via --idx flag. But, if this flag is not specified, auto-allocation would happen.
--peer flag which was used to specify another Dgraph instance’s IP address is being replaced by --zero flag. This flag would need the IP address : Port of a Dgraph zero instance.
--groups, --gentlecommit and a couple of other flags are now removed.
Embedded Dgraph goes away
We haven’t seen much usage of this feature. And it adds unnecessary maintenance overhead to the code. If there are clear reasons for its benefits, let us know (Remove support for embedded dgraph (and client_test) by peterstace · Pull Request #1734 · dgraph-io/dgraph · GitHub).
Go client
-
client.Unmarshalgoes away as client returnsjsonresponse as bytes. Now the user can usejson.Unmarshal. - Response for predicate of type
geocan now be unmarshalled into a struct. Example here https://godoc.org/github.com/dgraph-io/dgraph/client#example-package--SetObject
Facets
- Facets response structure has been modified and is a lot flatter. Facet key is now
predicate:facet_name.
Retrieving uid
Instead of fetching uid using _uid_, you can just use uid.
Diff of changes https://github.com/dgraph-io/dgraph/compare/release/v0.8.3...release/v0.9.0?expand=1
Give us your feedback
If there are specific things you need, let us know; so we can discuss them and potentially incorporate them before the release.
