I am using the Python DGraph client because I need to batch transactions atomically, and that’s the only way I can figure out how to do it.
I have figured out how to add/query, but I am looking at updating an object. I am looking at this comment as an example but I have been using the js object format and I’m not sure how I should be doing this.
I understand that, I was using it as an example of an “add”.
For example, to add I have been doing this.
It would be nice to have more documentation on using the Python client, as that is the only way I can seem to do atomic transactions (which are critical for DBs).
This is what I am running. It runs without errors, but nothing changes.
Then looking over the upsert block docs, I get a totally different way of doing it. I am using the JS Object format for adds and queries, but I don’t think I can do that with Upserts. Also, I have no idea what this nquads are.
curl -H "Content-Type: application/rdf" -X POST localhost:8080/mutate?commitNow=true -d $'
upsert {
query {
q(func: eq(email, "user@company1.io")) {
v as uid
name
}
}
mutation {
set {
uid(v) <name> "first last" .
uid(v) <email> "user@company1.io" .
}
}
}' | jq
I understand this is via Curl, but I am specifically referring to the upsert block syntax.
Because I have a txn.commit() in there, and specifically because I want to do more than one transaction (some are not upserts) so I want to commit manually.
Would you mind testing with true? so then you can keep doing as you are doing. That would isolate possible issues related to handling a transaction manually.
Weird, I’m not a Py dev. But looks like it is all good. Would mind changing the variable “upsert” to “query” instead? Maybe this creates a named object in the method. And when it runs it fails cuz it is expecting “query” instead.
I have done that as well, it was query initially but since it isn’t sent to the server (since it is a local python variable name) it won’t affect anything.
Sorry about all the issues you’re facing. I really want to ensure that our documentation is top-notch. Would it be possible for you to jump on a call with @vvbalaji regarding the documentation issues you’re facing? It would help us improve the experience for you and for all the other folks who come after you.
@billybobthorton: could you share your availability (if you prefer over email vvbalaji@dgraph.io) so that we can set up a call to understand and addres your pain points?
Can you share your GraphQL schema ? (specifically the type definition of node, 0x1fbd2 )
Is the predicate prize a field of some object in GraphQL schema ?
The prize predicate of the node won’t get affected if it is not part of the schema and the backend is being run in GraphQL mode.
By default, Slash GraphQL runs in GraphQL mode which does not allow adding predicate values which are not part of schema. You will have to use flexible mode to make changes to predicates using DQL.
Other reason for prize predicate not getting affected could be related to mapping of GraphQL and DQL predicates.
Consider this type in GraphQL schema,
type User {
prize: String!
name: String!
}
When this schema is applied, Dgraph internally creates 2 predicates with the name, User.prize and User.name. The prize field is mapped to User.prize predicate in Dgraph.
In case, after inserting GraphQL schema, you want to perform some operations using DQL, you will have to use their Dgraph mappings, User.prize and User.name for these operations.
Do let us know if this solves your issue or if you face any other problems.
Why is a 1- put in front? My guess is this is related to the problems I am having.
I have two applications I need to build, I have the clients who will be accessing via GraphQL exclusively, mostly subscriptions and then the backend application which will need to use DQL as it needs to commit multiple transactions as one.
From the example in the previous posts above, with the predicates User.prize and User.name you should not be getting the response 1-prize, but rather 1-User.prize if done correctly.
