I need to ensure that some fields of my types are unique.
Like for example the email of a user.
I used the Upsert Block for this. And it’s working.
Only when the email doesn’t exist a new User is added to the db.
But how can I now if a user was created or not?
I see no field in the response directly telling me this. I can just guess if the affteced uids is bigger then 2, it seems to be success otherwise the upsert query condition blocked the mutation.
interesting,
can’t I just use the dgraph-toucheduids key from the response?
as the user creation will affect some more data, that number should be higher then?
but instead of query again, I could also do a query first, check the result and then decide to either execute the mutation or not?
Then upsert is not needed, and it’s one query less.
Yes, but you need to know which one they are. So a new query is needed. Or you have to identify them in your app.
Not sure, you have to test it out. Touched UIDs was created to use in the GraphQL context if I’m not mistaking. Not sure how useful for your case it is.
No, Just create a very precise Upsert Query and trust on it. Do several tests to see the behavior of your query. And then just trust it.
If you wanna uniqueness and less transactions, Upsert Block is very useful.
hm can’t I just do the query in a transaction so it is similar to upsert but I know the result?
If I try to check it afterward with a query it could be difficult.
Let’s assume the only thing I need to register for a new user is the email.
In case another user is already registered with that email I don’t know if the new registration was successful as in both cases (insert or blocked) I will find a user with this email.
I could add an additional parameter like the registration time to check it. But doing it like this. Would in the end also be the same as just query before the mutation
As in theory between query and mutation, another mutation for the same email address could happen. But this would also be the case if I query afterwords.
That hypothesis is invalid for a new account cuz two different person can’t have the same email from the same service provider. Let’s assume a third person have stolen Bob’s email and somehow he was able to create an account in your service. And then the real Bob come back and try to create an account with the same email. Well, if Bob have recovered his email. Your job is to offer him a way to recover that account too. You choose the strategy. Send him a recover method.
Ignoring that, if Bob tries to create an account with an existing account that he doesn’t remember exists. Your upsert will be able to tell that the account exists and ignore. So, if there is an account, the upsert will not execute and return “Done” and the values at the query request. Meaning that the user already exists. But if the user doesn’t exists, it will create one return “Done” along with the created UIDs in the UID key of the response. e.g:
{
"data": {
"q": [], # This is empty cuz there was no data before
"code": "Success",
"message": "Done",
"uids": {
"uid(v)": "0x1" # This returns the UID of the new node created.
}
},
"extensions": {...}
}
ok, email wasn’t the best example. It was more like that. Bob registered 1 month ago. Then he forgot he is registered and start a new registration. (Happens many times)
but based on your answer that’s what I need: if the mutation was executed I get the uid back. if not uids are empty.
(I think the response from your example is if you do an RDF request. But I do a JSON request)
I checked what I get in api.Response and there Response.Json is empty. there is nothing in.
But at least Response.Uids works
Thanks again
