Go Client - Parsing of Response from server

Users
1

Go Client right now gets back the response from the server as a protocol buffer. For it to be meaningful to the user.

  1. It has to be parsed to populate values of nodes in memory - This will be done in a bottom-up fashion(similar to ToJson).

  2. Helper functions need to be provided

    1. Getter methods
      • Value - Returns the value at that node if any.
      • HasValue - Returns a Boolean.
      • NumChildren - Returns number of children.
      • Children - Returns pointers to children nodes.

This is just an initial list based on my discussion with @mrjn. I might have missed some of these, feel free to add them, Manish.

2

Looks good!

Also, HasValue() bool

1 Like
3

@mrjn I had a question here.

query := `
	{
		me(_uid_:0x01) {
			name
			gender
			status
			friend {
				name
			}
		}
	}
`

Does the root(or any node with children[E.g. the node with attr=friend]) have a value or do only leaf nodes have a value?

I know that non-leaf nodes have a UID Matrix and not values directly, but in the parsed response , do they have values ? Because if they don’t have a value and only reference to Child nodes which may have a value, then the bottom up approach isn’t needed. We could pretty much use the protocol buffer struct then.

Or in the other method typically every node will have a value. For instance, the friend node would have a value that would be a slice of structs probably where each struct has a name property. In this case, the bottom-up approach would be needed.

4

Only leaf nodes will have a value. Because, if they have a value, there’s no way we can keep on iterating under them.

My thought was that we still needed the bottom up approach to figure out the tree structure under the entity. Do you think that’s not required?

Actually, maybe you’re right. As we iterate from top-down, if we need more info about some entity, we can just check if that entity exists in the children, and then lazily build it up.

5

Yes, so say if later we need to provide a helper function which gives you friends , we perform the bottom-up approach on that Subgraph(node with Attr=friends and its children) and get back the result. This way we don’t have to bloat up the memory at first load.

6

It’s times like these that you feel like having an online whiteboard, and a stylus :slight_smile:.

1 Like
7

@mrjn Well, I don’t have full clarity on this yet. So thought would share my doubts before implementing anything.

I am sharing a picture with you of the subgraph for the query in query_test.go. I feel if I can understand the implementation here 100%, then I would be ready to go ahead and implement this.

1080Ă—1920 294 KB

Sorry for my bad writing here. I think the main thing to understand here is how this subgraph would be modified to use on the client.

P.S. - Till we decide about the iPad and the stylus, I think old school paper and pen might just work for us :stuck_out_tongue:

8

The main issue here is that the organization of our response is based on “predicate” children; while the user should iterate in terms of “entity” children.

So, Node 2, 3 and 4 are all “value” nodes. Those should become part of Node 1 itself, stored as a key-value map.

Then regarding Node 5, there’re 5 UIDs there: 23, 24, 25, 31, 101. So, Node 1 has 5 children, with the attribute “friend”.

Each of these 5 children again would have a key-value map with the contents of Node 6 within them.

So, the graph would look something like this:

2448Ă—3264 957 KB

1 Like
9

A picture is worth a thousand words. I get it now.

1 Like
10

Some more queries.

Now that I understand the structure.

Each node would have the following methods

  1. Attribute - Returns the value of Attr.
  2. Properties - which would return the names of properties e.g. name, gender , status for Node 1.
  3. Property - which given a property name returns the value of the property from the map.
  4. Children - which would return pointers to children
  5. NumChildren

Where do Value and HasValue come in now ?

The feeling that I get is it that it would be easier to parse the response and load the whole tree structure in memory.

11

Methods:

  • Attribute string
  • Properties string
  • Value(property string) byte
  • HasValue(property string) bool
  • Children() *Node
  • NumChildren() int

I’d say try the iterative process first – unless it gets too hard, then we’ll see how we can optimize it.

1 Like
12

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.