So are you’re saying I need to include the predicate “likesComment” as a Person field? Many of my predicates are created upon mutation, because they are not part of the data within the Type files, but part of the edges instead.
What defines what is connected is the edge. If you have already created the edge, so now you need to set it on the Type definition on the schema (actually all should be already done on your Graph Modeling).
But, I’m not sure if that is the case. Something feels odd here. It should work even without the schema. Cuz the edge exists and you have set a minimum Type Definition. Not sure, try out what I said and let me know.
What I would see as an issue is by using expand(all) and other funcs.
So, you already have the users. Right? and this mutation
Would be your kind of “create the relation” right?
If that so, that’s wrong. Cuz you are not using a real UID or using an Upsert Block. This separation will create new nodes and not relations. You are creating 2 new nodes every time you run that mutation. And only those two will be connected by them selfs.
Let me know exactly what you are doing step by step.
Is there a way to do the upserting with live loader? The examples seem to handle it one case at a time…
Would reformatting my data a certain way enable me to automate the loading process any further?
I thought there was an issue with my query… would it be better to put no topic?
Okay, that’s fine. When a user chooses such topic I assume that he is familiar with it. But by reading your issue I notice that it isn’t related to GraphQL. So, all questions of any kind should go first to Users/Dgraph. And then we can move it (the staff) if needed.
But no problem at all.
You can use upsert for this. See, custom IDs aren’t handled by Dgraph. So Dgraph can’t be aware of its nature, patterns, standards, and so on. But you can still use your custom IDs, now you just need to learn how to use Upsert Block on daily basis.
Got it, i’ll put new questions in the Dgraph topic.
I see, so there’s essentially no point of having UID for each Personid because DGraph will create its own UID upon loading. And in order to create a link from one Person object to another type, I would need to know the exact UID within the system to avoid creating a duplicate Person - am I getting this correctly?
One question, does your child data knows about the parent? I mean, to be able to link them without going one by one. One of the nodes needs to be aware of the other, so we can get that information and upsert right away. If not so, not even with dark magic would be possible.
See this query:
upsert {
query {
q(func: eq(Personid, "32985348833579")) {
v as uid
}
q2(func: eq(Commentid, "2061584302097")) {
v2 as uid
}
}
mutation {
set {
uid(v) <likesComment> uid(v2) (likeDate="2012-09-07T16:44:37.850+0000") .
}
}
}
That would be a simple example. But to do an upsert that connects every node. Some of them have to be the source of truth of the context. If your data comes from other DB, maybe they export that info. Need to evaluate.
I think you mean having “custom” ID system right? Yeah, in that case it’s up to you to deal with other IDs systems. I see that other users use third party IDs, cuz they combine Dgraph with other DBs. So, in their case makes sense they do that work.
