Relationship/Edge Name as node id breaking in bulkloader


(nyadav) #1

hi,

OS : Windows 10
Dgraph version : 1.0.9

For my usecase i had modelled each relation name also as node and that node id
was using as edge name to create relations. Tested end to End this is working in dgraph.

Reason for this modelling was wanted to allow relation names to be changed on choice at any stage.

Problem came with dgraph bulkloader because i am trying something odd.

Schema file :

name:string @index(term,trigram) . 
<_:uid3>:uid @reverse .

RDF file :

<_:uid1> <name> "India"^^<xs:string> .
<_:uid2> <name> "Pune"^^<xs:string> .
<_:uid3> <name> "hasCity"^^<xs:string> .
<_:uid1> <_:uid3> <_:uid2>.

This run with bulkloader but it gives _uid3 as edgename.
I was expecting it to be generated uid of hasCity node.

I know this is not normal to be supported but just want to see if any workaround or new idea come up
for my problem.

Thanks in advance.


(Daniel Mai) #2

It sounds like what you want is the relationship of “India has the city Pune”, so the predicate name should be hasCity.

You can generate an RDF file up-front with the expected structure and names and then load your generated RDF file into Dgraph.


(nyadav) #3

actually i wanted
India 0x1 Pune
0x1 will be node id of hasCity relation geneated by dgraph in same rdf file processing.

If you relook my post i had mentioned same and accordingly planned rdf file.


(Michel Conrado (Support Engineer)) #4

What Dmai says is that you should do like this:

name: string @index(term,trigram) . 
hasCity: uid @reverse .
<_:uid1> <name> "India"^^<xs:string> .
<_:uid2> <name> "Pune"^^<xs:string> .
<_:uid1> <hasCity> <_:uid2>.

You can never mix _:Blank_nodes with predicates.

Note: If your predicate is a URI or has special characters, then you should wrap it with angular brackets while doing the schema mutation. E.g. <first:name>

Despite the wrong use, in theory you should do so:

<_:uid1> <<_:uid3>> <_:uid2> .

But I’m not sure it will work. But notice, this use does not make much sense and does not seem practical to me. I suggest you follow what is recommended in the documentation.

Cheers.